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Abstract 

The Web Service Choreography Interface (WSCI) is an XML-based interface 
description language that describes the flow of messages exchanged by a Web 
Service participating in choreographed interactions with other services. 

WSCI describes the dynamic interface of the Web Service participating in a given 
message exchange by means of reusing the operations defined for a static 
interface. WSCI works in conjunction with the Web Service Description Language 
(WSDL), the basis for the W3C Web Services Description Working Group; it can, 
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also, work with another service definition language that exhibits the same 
characteristics as WSDL. 

WSCI describes the observable behavior of a Web Service. This is expressed in 
terms of temporal and logical dependencies among the exchanged messages, 
featuring sequencing rules, correlation, exception handling, and transactions. 
WSCI also describes the collective message exchange among interacting Web 
Services, thus providing a global, message-oriented view of the interactions. 

WSCI does not address the definition and the implementation of the internal 
processes that actually drive the message exchange. Rather, the goal of WSCI is 
to describe the observable behavior of a Web Service by means of a message- 
flow oriented interface. This description enables developers, architects and tools to 
describe and compose a global view of the dynamic of the message exchange by 
understanding the interactions with the web service. 

Status of This Document 

This document is a submission to the World Wide Web Consortium (see 
Submission Request, W3 C Staff Comm ent). This document is a NOTE made 
available by the W3C for discussion only. Publication of this Note by W3C 
indicates no endorsement of its content by W3C, nor that W3C has, is, or will be 
allocating any resources to the issues addressed by the Note. This document is a 
work in progress and may be updated, replaced, or rendered obsolete by other 
documents at any time. 

This draft proposes a language standard that can be used in conjunction with 
existing Web-service protocols to provide a description of the observable behavior 
of Web services. It is provided by the authors for consideration and review by the 
web services community. 

Feedback and comments are welcome and may be sent to BEA Systems 
(wsci@bea.com), Intalio (wsci@intalio.com), SAP AG (wsci-foedback@sap.com), 
or Sun Microsystems (wsci-feedback@sun.com). 

Please note that feedback to any one of these aliases is automatically shared 
amongst all co-editors. For more information on the shared privacy policy 
regarding any feedback information, please visit any of the co-editor's sites where 
the WSCI specification is now hosted. 

A list of current W3C Recommendations and other technical documents can be 
found at http://www.w3.org/TR. 
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1 . introduction 

1.1 Overview 

WSCI describes how Web Service operations - such as those defined by WSDL 
[WSDL]- can be choreographed in the context of a message exchange in which 
the Web Service participates. Interactions between services - either in a business 
context or not - always follow and implement choreographed message exchanges 
(processes). WSCI is the first step towards enabling the mapping of services as 
components realizing those processes. 
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WSCI also describes how the choreography of these operations should expose 
relevant information, such as message correlation, exception handling, transaction 
description and dynamic participation capabilities. 

WSCI does not assume that Web Services are from different companies, as in 
business-to-business; it can be used equally well to describe interfaces of 
components that represent internal organizational units or other applications within 
the enterprise. Again, WSCI does not address the definition of the process driving 
the message exchange or the definition of the internal behavior of each Web 
Service. 

WSCI describes the interdependencies among the Web Service's operations so 
that any client: 

• Can understand how to interact with such service in the context of the given 
process; and 

• Can "anticipate" the expected behavior of such service at any point in the 
process' lifecycle. 

Being able to describe the dynamic interface of a service in the context of a 
particular process enables the developer/architect to abstract from the 
implementation and to focus on the role the Web Service plays in such process. 

1 .2 The Reference Framework 

Web Services are a key component of the emerging, loosely coupled, Web-based 
computing architecture. A Web Service is an autonomous, well-defined, 
standards-based component that can be accessed via established Web-based 
protocols. 

A "stack" of layered standards is emerging that aims to ensure semantic and 
technical interoperability of Web Services. This stack, developed by the W3C, is 
still in its early stages and is currently being built from the ground up; several 
additional layers are needed in order to enable true Web Service collaborations. 
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In parallel, other standards are building semantics and interoperability for business 
processes and collaborations in a top-down approach. 

It is anticipated that these two stacks will meet in the middle. Although there is still 
a need for an overall architecture to make this happen in an effective way, WSCI 
provides the first step to linking the two. 

WSCI is primarily a participant in the bottom-up stack, but it anticipates the 
emergence and integration of higher-level layers in the area of collaboration. 

1.3 Problem 

1.3.1 The current Web Services stack 

The current Web Service stack does not define a choreography language or any 
other relationship among atomic operations. It does, however, provide the basic 
layers: 

• SOAP defines the basic formatting of a message and the basic delivery 
options. A SOAP compliant Web Service knows how to send and receive 
SOAP-based messages 

• WSDL describes the static interface of a Web Service. It defines the protocol 
and the message characteristics of end points by means of four basic 
operations; a WSDL compliant Web Service knows how to support any of 
these four operations. The operations defined in this way: 

o Are atomic in nature (that is, no intermediate state is visible from the 
outside) 

o Describe the direction of messages (incoming or outgoing) but not the 
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behavior of the service as a result of each individual operation. 

The current Web Service technologies may be adequate for simple information 
retrieval in a stateless message exchange, such as a stock quote Web Service; for 
some services, it may even be sufficient for messages to maintain state in remote 
procedure calls by passing tokens or state variables within objects. 

1.3.2 The need for describing complex interactions 

Most Web Services, however: 

• Participate in longer conversations, spanning beyond the boundaries of a 
single operation. In these conversations, the ability to perform certain 
operations depends upon the previous exchange of messages as well as the 
way to interpret the content of each message may be influenced by the 
previous exchange. 

• Provide compound services, rather than atomic actions. For instance, this is 
the case of Web Services that interact with complex back-end business 
processes. Such processes are often automated and require a defined 
choreography of messages to properly operate and provide the service that 
is required. 

Therefore, there is a need to address questions such as the following: 

. Can messages be sent and/or received in any order? 
Without a clean and precise description of the message choreography 
supported by the Web Service, it would be difficult for a client - which wants 
to interact with the service - to properly understand the sequence of 
messages the Web Service is expecting and the sequence of messages it 
will deliver. 

• What rules govern sequencing of messages? 

Without a precise description of the way in which information carried by the 
exchanged messages affect the observable behavior of a Web Service, it 
would be difficult for a client to properly manage situations in which 
messages of different types can be expected depending upon the value of 
some condition. 

• Is there any relation among any incoming and/or outgoing messages? 

In order to properly prepare and interpret the messages that are exchanged 
within a given process, it is very important to understand and describe the 
correlation between these messages, i.e. the mechanism by which the Web 
Service can manage concurrent conversations. 

• Is there a "start" and an "end" of a given sequence? Can a given sequence 
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be partially "undone"? 

In order for a Web Service to be part of a long message exchange, it is 
important to clearly define when the message exchange is actually triggered, 
when it is considered to terminate and which parts of it can be considered as 
managed in a transactional way. 

• Can a global view of the overall exchange of messages be drawn ? 

A static Web Service definition language alone does not address the need 
for composing a global model of how two (or more) Web Services interact. 
Without something like WSCI, it is not possible to understand how the 
services interoperate and thus: 

o To verify if the service behaved as stated by a given process 
specification 

o To derive the choreography of the overall process to describe and thus, 
potentially, to modify it. 

o To monitor the behavior of the service on respect to all other 
participants in the message exchange 

1.4 Challenges 

The answers to questions such as the ones listed in the previous section are 
addressed by EAI middleware in a traditional, intra-enterprise environment,. But 
the loosely coupled, distributed nature of the Web prevents a central authority (or 
a centralized implementation of a middleware) from exhaustively and fully 
coordinating and monitoring the activities of the enterprise applications that 
expose the Web Services actually participating in the message exchanges. The 
reasons are: 

• Traditional workflow models rely on message-based computing methods that 
are tightly coupled to protocols for business-to-business or application 
integration. These protocols assume a different, more tightly linked and 
controllable environment, which is not the nature of the Web. 

• Participants in traditional workflow are, normally, known in advance. When 
moving to the Web environment, it is very likely that Web Services will be 
dynamically chosen to fulfill certain roles. 

• Traditional models normally call for centralized engines, while the nature of 
the Web is decentralized. 

This provides a fundamental challenge in defining and running a complex, 
process-aware Web Service based on traditional workflow models. 
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Thus, the challenge for WSCI is to provide answers to the previous (and other 
related) questions in the domain of the Web based computing. Fundamentally, the 
challenge will be to describe Web Services: 

• From an external point of view (without knowing how internally they operate) 

• Independently of any particular integration model (workflow, MOM etc) 

• Precisely enough to allow other components to have a clear understanding 
of how to properly interact with them. 

• In the context of each specific message exchange in which they participate. 

1.5 Solution 

To be part of a useful and manageable Web Service collaboration, individual 
operations must be allowed to convey enough information about how they can be 
used in a given scenario in order to enable them to participate in more complex 
processes. 

WSCI achieves this by defining a layer on top of the existing Web Service stack. 
This layer describes the required behavior of a Web Service relative to the 
message exchange it must support. 

WSCI supports the following key requirements for a long lasting, choreographed, 
stateful message exchange: 

• Message choreography: a WSCI interface describes the order in which 
messages can be sent or received in a given message exchange, the rules 
which govern such ordering, the boundaries of a message exchange (when it 
starts and when it ends). 

WSCI does not define how the Web Service internally manages such 
choreography. Instead, it allows a Web Service to assert what is the 
observable choreography of messages it is capable of managing in the 
context of a given message exchange. 

• Transaction boundaries and compensation: A WSCI interface describes 
which operations are performed in a transactional way and, thus, informs 
other participants of the capability of such Web Service to perform these 
operations in an "all or nothing" way. This capability also enables the Web 
Service to eventually join a distributed transaction with other services with 
which it interacts. 

WSCI does not define a two-phase commit protocol over the Web or how 
transactions are carried over by Web Services. Rather, it allows a Web 
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Service to assert when it is capable of managing operations in a 
transactional way, to precisely define the transaction boundaries and the 
externally observable compensation behavior. 

• Exception handling: A WSCI interface describes how the Web Service will 
react when exceptional conditions happen, thus providing a description of 
alternative patterns of behavior. 

However, WSCI itself does not define the mechanism by which a Web 
Service reacts and manages exceptional situations and faults. Again, it 
allows a Web Service to describe its observable behavior when it's dealing 
with deviations from the normal behavior. 

• Thread management: A WSCI interface describes if and how a Web 

Service is capable of managing multiple conversations (based on the same 
message exchange) with the same partner or with different partners. In the 
same way, it also describes the required relationship among parts of different 
messages belonging to the same message exchange. 

WSCI does not define how the Web Service is capable of managing multiple 
conversations in a concurrent way. It allows a Web Service to assert the 
observable elements of the exchanged messages that allow it to properly 
treat each conversation separately from the others. Further, WSCI allows a 
Web Service to describe the relationships among the parts of different 
messages that collectively guarantee the consistency of the message 
exchange. 

• Properties and Selectors: A WSCI interface describes the elements that 
influence the observable behavior of a Web Service, such as alternatives 
based on the runtime values of some parts of the messages. 

Although WSCI is not an executable language that provides the semantic for 
variables used to automate it, it allows a Web Service to assert which are the 
relevant elements of the exchanged messages that influence its observable 
behavior at any given time. 

• Connectors: A WSCI interface describes how the operations performed by 
different Web Services acting in the same message exchange actually link 
together. WSCI enables the mapping of "consume" operations from a Web 
Service to "produce" operations from another Web Service in order to 
unambiguously build a model of the global exchange. By means of the WSCI 
Global Model it is also possible to describe how interfaces from different 
services participating in the same message exchange can be linked together 
to build the end-to-end model of interactions. 

WSCI does not define the middleware connecting the Web Services involved 
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in the message exchange, nor does it define the order in which different Web 
Services happen in the course of a message exchange. 

• Operational context: A WSCI interface describes how the same Web 
Service behaves in the context of different message exchanges. 

Different WSCI interfaces (observable behaviors) can be associated with the 
different operational contexts in which the Web Service participates. WSCI 
does not define the behavior of a Web Service independently on how it is 
used. 

• Dynamic participation: A WSCI interface describes how the identity of the 
target service is dynamically selected. This selection is based on some 
criteria that are known at runtime and that depend on information described 
by the WSCI interface itself, such as message parts. By knowing the 
properties used to identify the target service, it is possible to understand 
how, changing the value of such properties, the behavior of the 
corresponding service is affected. 

The definition of a particular mechanism used to identify the target service is 
out of the scope of WSCI and can be addressed by existing and future 
specifications. 

In summary, a WSCI interface describes all the artifacts required to provide: 

• The external, observable view of how the Web Service interacts with other 
services within a given message exchange, or, in other words, how the Web 
Service is perceived to behave by the external world in the context of a given 
message exchange, 

• The view of the message exchange as seen by the Web Service, or, in other 
words, how the Web Service perceives the behavior of the external world in 
the context of a given message exchange. 

In doing this, the interface promotes the capabilities the Web Service provides in a 
given message exchange (transactional, correlation etc). 

The above features and concepts are described in further detail in subsequent 
sections of this specification. 

1 .6 External Architecture 

WSCI defines a new layer in the emerging stack of standards associated to Web 
Services. 

WSCI works on top of the current Web Service stack and below layers in the 



http://www.w3.org/TR/wsci/ 



5/8/2007 



Web Service Choreography Interface (WSCI) 1.0 



Page 13 of 128 



emerging Web Service architectural model that may be thought of as process or 
collaboration modeling layers. 

WSCI describes the interface between an implementation and the message 
exchange (collaboration) in which it participates. 




Figure 1-2 



1.6.1 Relationship to Web Service Description Language (WSDL) 

WSCI is designed to work in conjunction with Web Service description languages, 
which provide the static interface of a Web Service. While WSCI can work with 
different description languages, particular attention is devoted to the binding to 
WSDL, which is the basis for the W3C Web Services Description Working Group 
and rapidly gaining momentum. 

Both WSDL and WSCI can be seen as interfaces. WSDL describes a static 
interface that evenly lists the entry points to the service. WSCI describes the 
dynamic interface by providing for the interrelationship between multiple 
operations in the context of a well-defined message exchanges. The very idea of 
WSCI as an interface lies in the fact that it can operate on WSDL (or any other 
static description language) artifacts, which are mainly messages exchanged by 
services. 
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When used in conjunction with WSDL, WSCI enables the description of complex 
choreographies across multiple operations as defined by WSDL. The messages 
and their associated "operations", "services", "ports" are directly referenced from 
the relevant WSDL definitions. Where WSDL describes each "operation" in a 
vacuum, WSCI enables the description of complex choreographies across multiple 
"operations". One of the basic concepts of WSCI - Action - directly maps to the 
execution of any of the four types of WSDL operations. 

Whilst it is possible for a static description language to provide a single interface 
for a Web Service, it is very likely that the same Web Service exhibits more than 
one WSCI interface; each WSCI interface describes the observable behavior of 
that service in a specific message exchange context. It is also possible that the 
behavior in the same message exchange context would be described by multiple 
WSCI interfaces, each one providing a "view" for a different party. 

1.6.2 Relationship to Implementations 

WSCI is an interface description language. It describes the observable behavior of 
a service and the rules for interacting with the service from the outside. It does not 
specify the possible implementation on the inside. It is declarative and cannot, by 
itself, be executed. However, it is precise and unambiguous enough that external 
actors will know at each stage in the given process which messages that service 
may or must send or receive next. 

The observable behavior of each party in a message exchange is described 
independently of the others; each party could actually be implemented by 
completely abstracting from its WSCI description; WSCI's main goal is to describe 
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an observable behavior, not to define how the implementation works. 

Thus, in a message exchange, any Web Service described by WSCI can interact 
with: 

• Other Web Services, whose implementation has been derived by their WSCI 
description 

• 'Hard-coded' software components with internally encoded mechanisms to 
guarantee the correct sequence of the exchange 

• Or human controlled software agents where the human determines the 
sequence of interaction within the constraints of the WSCI description. 

For that matter, the message exchange could actually be several human 
controlled software agents interacting. 

Although WSCI has no explicit constructs for implementation, it is assumed that 
every sending of a message is mapped to some identifiable processing in the 
implementation (actually, the processing required for or resulting in the sending of 
the message). Likewise, it is assumed that every receipt of a message is mapped 
to some identifiable processing in the implementation (actually, the processing 
triggered by the receipt of the message). 

Non-observable mappings, such as the use of some internal software are outside 
the scope of WSCI. 

A specific kind of mapping between messages and implementation that may be 
observable is the recursive use of services, so that an incoming message might 
cause the invocation of another lower level or auxiliary service through a separate 
message exchange. 

1.6.3 Relationship to Collaborations 

Business processes are increasingly relying upon collaboration. Businesses must 
automate these collaborative processes in order to achieve greater productivity. 
Likewise, government agencies, educational institutions, and non-profit 
organizations are looking to Web-based collaboration to increase efficiency and 
expand horizons. 

The ultimate purpose for a Web Service is to facilitate such collaborations; in order 
for a Web Service to fully represent the role of a participant in these collaborations 
and to properly grant the required level of interoperability, many layers of 
capabilities need to be addressed. 
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Figure 1-4 



Whilst a process or collaboration modeling language may support full definition of 
roles, responsibilities, contracts, artifacts, state management and state transitions, 
the goal of WSCI is to present the interface that a given Web Service exhibits in 
such a complex scenario, when it is called to cover one or more roles. 

Thus, when used in a collaboration context, the objective of WSCI is to 
unambiguously describe the choreography of message exchanges that involve a 
specific Web Service covering one (or more) role(s) in such collaboration. Each 
Web Service is considered a peer in the collaboration and, as such, exhibits its 
own interface as part of the collaboration. 

1.6.4 Relationship to Workflow 

WSCI is not a "workflow description language"; it is envisaged that this role will be 
covered by some other specification that would properly address the description of 
collaborative processes. 

WSCI can describe the observable behavior of a Web Service interacting with a 
workflow; as well, it can describe the observable behavior of a system that 
implements a workflow (or which behaves as such). 
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WSCI does not address the definition of the behavior required by a Web Service 
when it needs to coordinate its own activities with the activities performed by other 
Web Services; but it can describe the observable behavior of a Web Service 
behaving as such. 

Thus, in a model describing the way in which multiple participants interact, WSCI 
addresses the description of the "boundaries" for each participant. 

1.7 Simple Example 

The example presented in Section 5, taken from the well-known Travel 
Reservation System use case, describes the use of most of the WSCI features in 
the context of a real-life example. 

In order to familiarize the reader with key WSCI artifacts, a subset of the full 
example is presented here. This subset does not account for all the modeling 
possibilities offered by WSCI but is simple enough to show its power. Se ction 3 
provides a more thorough description of how additional WSCI features can be 
used to better model the overall scenario and to arrive to the full-fledged model 
described in Section 5's example. 

1.7.1 Scope 

The following example illustrates, in the scope of a real life use case, how WSCI 
models the following concepts: 

• The Action, the basic construct of WSCI, and its binding to some WSDL 
operation 

• How multiple actions are choreographed in a simple sequence 

• How groups of actions can be grouped in a process which represents an 
identifiable (and reusable) behavior exhibited by the Web Service 

• The use of Correlation to describe how messages exchanged within a 
choreography are related 

• How to define the WSCI interface of a Web Service 

1.7.2 Simple scenario 

The scenario describes the basic behavior that is exposed by a Web Service 
implementing the functionalities of a Travel Agent in a Travel Reservation System; 
this scenario will be enhanced in Section 5 to better reflect the real-life use case 
and to show the use of the majority of the WSCI language features. 
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In this scenario, the Travel Agent only interacts with a Traveler according to a very 
simplified choreography: 

1 . A Traveler can order a trip with the Travel Agent 

2. Some time later, the Traveler confirms the previous order 

3. The Travel Agent bills the Traveler for the trip 




Figure 1-5 



The goal is to show how WSCI enhances the model provided by WSDL. 



1.7.3 The static definition 



Here is a representation of the Travel Agent Web Service as provided by a static 
definition language, such as WSDL. 

<? xml version = "1.0" ?> 

<def initions name = "Travel Agent Static Interface" 

targetName space = "http: / /'example . com/ consumer /TravelAgent" 
xmlns : xsd = "http : / /www . w3 . org/2 0 00/10 /XMLSchema" 
xmlns:tns = "http: / /example . com/consumer /TravelAgent" 
xmlns = "http://schemas.xmlsoap.org/wsdl/"> 



<types> 

<schema xmlns = "http://www.w3.org/2 000/10/XKLSchema"> 



**************** COMPLEX TYPES ******************** 

<complexType name = "Traveler"> 
<sequence> 

<element name = "name" type = "xsd: string" /> 
<element name = "travelerlD" type = "xsd: string" 

</sequence> 

< / complex Type > 
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<complexType name = "trip"> 
- f ence> 

<el.ement name = " itinerarylD" type = "xsd: string" /> 
<element name = "startDate" type = "date" /> 
<element name = "startCity" type = "xsd: string" /> 
<element name = "arrivalDate" type = "date" /> 
<element name = "destinationAirport" 

type = "xsd: string"/> 
<element name = "numberOf Seats" 

type = "nonNegativeInteger"/> 
<element name = "pref erredCarrier " 

type = "xsd: string" /> 
<element name = "comments" type = "xsd: string" /> 
</sequence> 
</ complexType> 

<complexType name = "proposedItinerary"> 
ice> 

<element name = "itinerarylD" type = "xsd: string" /> 
<element name = "startTime" type = "timelnstant" /> 
<element name = "startAirport" type = "xsd: string" /> 
<element name = "destinationTime" 

type = "timelnstant" /> 
<element name = "destinationAirport" 

type = "xsd: string" /> 
<element name = "carrier" type = "xsd: string" /> 
<element name = "availability" type = "boolean" /> 
<element name = "totalCost" type = "float" /> 
<element name = "validityDeadline" 

type = "timelnstant" /> 

</complexType> 



<complexType nam' 
<sequence> 

<element name - 

<element name ; 

<element name ■■ 

<ele: 

<element nam. 
</sequence> 
</complexType> 



axe ■ 



"bookingID" type = "xsd : string" /> 
"creditCard" type = "tns : CCInf o" /> 
"date" type = "date" /> 
"amount" type = "float"/> 
"transactionID" type = "xsd : string" /> 



<complexType name = "CCInfo"> 
<sequence> 

<element nairie = "number" type = "xsd:. 
<element name = "issuer" type = "xsd:, 
<element name = "expiryDate" type = "i 
</sequence> 
</ complexType> 
</'schema> 
</types> 
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<message name = "tripOrderRequest"> 

<part name = "traveler" type = "tns : traveler" /> 
<part name = "trip" type = "tns:trip"/> 

</message> 



<message name = "tripOrderAcknowledgement"> 

<part name = "proposedltinerary" type = "tns : proposedltinerary" /> 
</rr.essage> 



<message name = "bookingRequest"> 

<part name = "itinerarylD" type = "xsd: string"/> 
</message> 

<message name = "bookingConf irmation"> 

<part name = "bookingID" type = "xsd : string" /> 
<part name = "status" type = "xsd : string" /> 

< / mess age > 

<message name = "statement"^ 

<part name = "bookingID" type = "xsd: st.ring"/> 
<part name = "body" type = "tns : statement" /> 



_ ************* TRAVEIj AGENT PORT TYPES ************************* 

<port.Type name = "TAtoTraveler"> 
<documentation> 

This port type references the operations the Travel Agent 

performs with the Traveler service 
</documentation> 



<operation name = "OrderTrip"> 

<input message = "tns : tripOrderRequest " /> 

<output message = "tns : tripOrderAcknowledgement " /> 

</operation> 

<operation name = "bookTickets"> 

<input message = "tns :bookingRequest"/> 
<output message = "tns : bookingConf irmation"/> 

</ operat ion> 



<operation name = "SendStatement"> 

<output message = "tns : statement" /> 

</operation> 
<7portType> 
</def initions> 



1.7.4 What is missing 

From the previous example, it is clear that a static interface, whilst able to capture 
important information about the atomic operations that are performed by the Travel 
Agent Web Service, is not enough to cope with: 



http://www.w3.org/TR/wsci/ 



5/8/2007 



Web Service Choreography Interface (WSCI) 1.0 



Page 21 of 128 



• Choreography aspects. 

The WSDL definition does not describe how to interpret a set of operations 
happening in a given order; in this example, it is not clear if all the 3 
operations supported by the Travel Agent Web Service should happen (and 
in which order) in order for a Traveler to complete the reservation of a trip. 

• Correlation aspects. 

Even if exposing the basic choreography of the supported operations, it is 
not possible to describe which information allow the Travel Agent Web 
Service to associate a confirmation request with a previously submitted trip 
request. 

Other important behavioral elements that are introduced in the following sections 
include: 

• Transactions. 

The WSDL definitions of the Travel Agent Web Service does not describe if 
the Web Service operations are performed in a transactional way. It may be 
important for the Traveler to know that a trip request would be logically rolled 
back in case of any error happening during the process. 

• Possible Choices. 

In real life, the Travel Agent Web Service may be able to choose the 
execution of different actions based on some information that can be carried 
in the message exchange: 

o The Web Service may be able to accept a Confirmation request or a 
Cancellation request and it will react accordingly. In this case the 
choice is based on the type of the incoming message. 

o The Web Service may be able to send either a Bill or a Notification that 
the trip cannot be confirmed based on the validity of the Credit Card 
info provided by the Traveler or based on the availability of the trip as 
communicated by the Airline Reservation system. 

1.7.5 The WSCI definition 

The following code example shows how the previous WSDL static interface can be 
enriched using WSCI concepts. 

<? xml version = "1.0" ?> 

<wsdl : definitions name = "Travel Agent Dynamic Interface" 

target/Namespace = "http: //example . com/consumer/TravelAgent" 

xmlns : wsdi = "http : // schemas . xml soap . org/wsdl/ " 

xmlns : xsd = "http : //www. w3 . org/2000/ 10/XMLScherna" 

xmlns : tns = "http: //example . com/consumer/TravelAgent" 

xmlns = "http://www.w3.org/2002/07/wscil0"> 1. 
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<!-- WSDL complex types — > 2. 

<!-- WSDL message definitions — > 

<!-- WSDL operations and port types — > 

<! — selectors --> 



^correlation name = "itineraryCorrelation" 
property = "tns : itineraryID"> 

</correlation> 



^interface name = "TravelAgent"> 4. 
<process name = "PlanAndBookTrip" 5. 
instantiation = "message"> 6. 



<sequence> 7 . 

Oction name = "ReceiveTripOrder " 8. 

role = "tns:TravelAgent" 9. 

operation = "tns : TAtoTraveler /OrderTrip"> 10. 

</action> 

Oction name = "ReceiveConf irmation" 11. 
role = "tns: TravelAgent" 

operation = "tns : TAtoTraveler /bookTickets"> 
<correlate correlation="tns : itineraryCorrelation" /> 12 . 

<call process = "tns : BookSeats " /> 13. 
</action> 



Oction name = "SendStatement" 14. 
role = "tns : TravelAgent" 

operation = "tns : TAtoTraveler /SendStatement " /> 

</sequence> 
</ P rocess> 

<process name = "EookSeats" instantiation = "other"> 15. 
<action name = "bookSeats" 
role = "tns : TravelAgent" 

operation = "tns : TAtoAirline/bookSeats"> 
</action> 
</process> 
</interface> 
</wsdl :def initions> 



The important information that the WSCI interface provides on top of the static 
WSDL interface: 

1. The WSCI interface definition is embedded inside the wsdl:definitions 
element; it does not require a root element nor does it require to be written in 
a separate file. The reason for this choice is explained in Section 3.1 .2. 

2. The standard WSDL definitions for types, messages, operations and 
portTypes as seen in the previous code example (see Section 1,7,3) apply. 
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3. The itineraryCorrelation definition indicates that messages carrying the same 
itinerarylD refer to the same trip; this will help the implementation of the Web 
Service to properly manage concurrent executions of the same message 
exchange (from the same or different users). 

4. The interface element is the WSCI container; it is designed to contain all the 
WSCI process definitions that describe the dynamic behavior of the Web 
Service in the context of a given message exchange (in our case, the Travel 
Reservation System process). 

Each WSCI interface has a name to properly distinguish multiple interfaces 
exposed by the same Web Service. 

5. The PlanAndBookTrip process models the observable behavior of the Travel 
Agent Web Service in the context of the Travel Reservation System process; 
thus it describes how the Travel Agent Web Service behaves in that context. 

The PlanAndBookTrip is the image of the Travel Reservation System 
process as seen by the Travel Agent Web Service. 

The process element is, in WSCI, the basic unit of re-use; thus an interface 
can only contain process definitions. 

6. The process is qualified with the "instantiation=message" attribute. This 
means that the execution of the process will be triggered as soon as the first 
action referred to by the process is ready. In this case, the PlanAndBookTrip 
process will be triggered when the tripOrderRequest message is received by 
the Travel Agent Web Service (this is the consume message referenced by 
the OrderTrip operation). 

7. The sequence construct indicates that the 3 WSCI actions are executed 
sequentially. 

According to this, the Web Service highlights that the 3 WSDL operations 
associated with the 3 WSCI actions cannot happen just in any order but that 
the Travel Agent Web Service can engage in the Travel Reservation System 
process {PlanAndBookTrip) only by performing the 3 actions in the correct 
order. 

8. The action is the basic WSCI construct; it identifies a unit of work associated 
with a given operation. 

Here, the WSCI interface describes that the Travel Agent executes the 
OrderTrip operation whilst performing the ReceiveTripOrder action. 

9. A WSCI interface can describe the observable behavior of a Web Service in 
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the context of a given message exchange. The Web Service can represent 
more than one logical role in such exchange; the "roie=traveiAgent" 
attribute specifies that the ReceiveTripOrder action is executed on behalf of 
the travelAgent role. 

10. The operation attribute associates the WSCI action with a WSDL operation 
as specified by the WSDL definitions. Via this operation, it will be possible to 
determine the type of the operation (1-way or 2-way), the messages that are 
actually exchanged and the bindings. 

1 1 . The ReceiveConfirmation is the second action in the sequence; after 
accepting a trip order from the Traveler, the Travel Agent Web Service is 
able to accept a confirmation for the booking. 

This means that if the Travel Agent Web Service receives another 
tripOrderRequest message, a new instance of the same process is created 
instead than continuing the current one. 

12. It is important to be able to correlate the ReceiveConfirmation action with the 
ReceiveTripOrder action that could have happened long time before; this is 
done via the reference to the itineraryCorrelation correlation. 

In this example, if the value of the itinerarylD field carried by the 
BookingRequest message is the same as the itinerarylD field carried by the 
previous tripOrderRequest message, then the ReceiveConfirmation action is 
part of an already established conversation (the one that was previously 
started when the ReceiveTripOrder action was executed). 

The itineraryCorrelation is implicitly instantiated when the ReceiveTripOrder 
action is executed. 

13. The BookSeats process is called as part of the WSCI action. This means 
that the actions defined by the BookSeats process are executed between the 
consume and the produce parts of the bookTickets operation. 

The use of the call construct allows re-use of process definitions. 

14. The SendStatement action does not require a Correlation since it references 
a produce operation. 

15. The BookSeats process is defined with "instantiation=other". This means 
that this process will never be instantiated by the reception of a triggering 
message but can only be instantiated when explicitly invoked. 

This process is not described in detail since it references the relations 
between the Travel Agent and the Airline Reservation system. 
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1.7.6 Benefits 

The simple WSCI example shown before highlights how WSCI can help the Web 
Service architect and programmer. 

• The architect of the Travel Agent Web Service can provide the WSCI 
definition of the service, along with the static definition. The WSCI definition 
is precise enough to describe the behavior of the Travel Agent Web Service 
when used inside the Ticket Reservation System process. 

This may become part of a standard worksheet associated with the Web 



• Anyone interested in interacting with the Travel Agent Web Service knows its 
expected behavior. A programmer that is interested in building a software 
agent for the Traveler can use the Travel Agent Web Service WSCI definition 
to properly build it. The WSCI definition allows the client programmer to 
clearly understand how to interact with the Travel Agent Web Service. 

• The WSCI interface could also be of help for the programmer of the Travel 
Agent Web Service itself. 

Sometimes WSCI can be used to describe the observable behavior of an 
existing Web Service; sometimes it can be used to define how a newly 
created Web Service should behave. In the latter case, the server 
programmer could use the WSCI definition to build the communication layer 
on the top of some legacy code that implements the basic functionalities of 
the Travel Agent service. 

1 .8 Notational Conventions 

1.8.1 Keywords 

The keywords "must", "must not", "required", "shall", "shall not", "should", 
"should not", "recommeni ed", "may", and "optional" in this document are to be 
interpreted as described in RFC-2119 [RFC 2119]. 

1.8.2 Namespaces 

The following namespace prefixes are used throughout this document: 
Prefix Namespace URI Definition 



Service. 



wsdl http://schemas.xmlsoap.org/wsdl/ 



WSDL namespace for WSDL 
framework. 
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xsd 



http://www.w3.orq/2001/XMLSchema 



Schema namespace as defined by 



wsci 



http ://www. w3 . orq/2002/07/wsci 1 0 



XSD. 

WSCI namespace as defined by 
this document. 



tns 



(various) 



The "this namespace" (tns) prefix 
is used as a convention to refer to 
the current document. 



(other) (various) 



All other namespace prefixes are 
samples only. In particular, URIs 
starting with "http://example.com" 
represent some application- 



dependent or context-dependent 
URI [RFC 2396]. 



1.8.3 Informal Syntax 

The definition of each WSCI element is given in XML-like grammar using the 
monospace typeface. The definition of an element is shown with the element name 
enclosed in angle brackets. 

Required attributes appear in bold typeface. Where the attribute type has an 
enumerated type definition, the values are shown as separated by vertical bars. 
Where the attribute type is given by a simple type definition, the type definition 
name from either XSD or the WSCI schema is used. Where the attribute is 
optional and has a default value, it is shown following a colon. 

Support for extension attributes is shown by {extension attribute}. Where used in 
the grammar, it indicates support for any number of attributes defined in a 
namespace other than the WSCI namespace. 

The allowed content of WSCI elements is shown using a simple grammar: 
• An element name is used for any content part that must be an element of 



• A name enclosed in curly braces and appearing in italic typeface refers to 
content parts of some other type. For example, {any activity} refers to any 
element that defines an activity. 

• Support for extension elements is shown by {extension element}. Where 
used in the grammar, the content part may be any element defined in a 
namespace other than the WSCI namespace. 

• Support for mixed content is shown by {mixed}. Where used in the grammar, 



that type 
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the allowed content is a mix of character data and of elements defined in any 
namespace. 

• The cardinality of any content part is specified using the operators "?" (zero 
or one), "*" (zero or more) and "+" (one or more). If no operator is used, the 
content part must appear exactly once. Cardinality that cannot be expressed 
using either operator is shown using curly braces, with the minimum and 
maximum values separated by comma, e.g. "{2,*}" denotes two or more. 

• Content parts may be grouped together using parentheses "( )" to form a 
new content part. A choice group consists of all consecutive content parts, 
separated by a vertical line "|". A sequence group consists of all consecutive 
content parts that are separated by a comma 

XSD schemas are provided as a formal definition of WSCI grammar (see WSCI 
Schema, Section 8.4 ) . 



2. Language Overview 

This section introduces the main modeling concepts underlying the WSCI interface 
and the WSCI model definitions as well as the extensibility features of the WSCI 
language. 

2.1 Concepts 

The following concepts are part of the underlying model: 

• Interface 

• Activities and choreography of activities 

• Processes and units of reuse 

• Properties 

• Context 

• Message correlation 

• Exceptions 

• Transactions and compensation activities 

• Global model 

2.1.1 Interface 

WSCI aims to describe how Web Services participate in choreographed, long- 
lasting and stateful message exchanges. More precisely, WSCI aims to describe 
the externally observable behavior of a Web Service in such a message 
exchange. The focus of the described behavior is on the temporal and logical 
dependencies among the messages the Web Service exchanges with one or more 
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other services in the context of a given scenario. WSCI maps this description to 
the notion of an interface. 

The details of the behavior of the Web Service are described in the processes that 
are contained in the interface. Usually, an interface contains at least one process 
whose execution can be initiated by the receipt of a message. This indicates that 
the service will not proactively perform the behavior described in that process, but 
instead will wait until triggered by the respective message. 

A Web Service may expose multiple interfaces for supporting multiple scenarios. 
In this sense, each interface describes how a Web Service is perceived to behave 
in the context of a particular scenario. A Web Service may also expose multiple 
interfaces for supporting different views of the behavior of the service in a single 
scenario. Such a view might, for instance, show only the interactions of the service 
with one specific client, thus allowing the client to fully understand how to interact 
with the service in that scenario. 

2.1.2 Activities and their choreography 

WSCI describes the behavior of a Web service in terms of choreographed 
activities. Activities may be atomic or complex, i.e. recursively composed of other 
activities. Choreography describes temporal and/or logical dependencies among 
activities. 

Atomic activities represent the basic unit of behavior of a Web service, such as 
sending and/or receiving a message, or waiting for a specified amount of time. 
They are termed atomic because any observer of the Web service cannot observe 
intermediate states during their execution. Atomic activities dealing with messages 
correspond to the execution of operations defined in static service definition 
languages such as WSDL. 

Complex activities are recursively composed of other activities; ultimately, each 
complex activity is composed of actions. Each complex activity defines a specific 
kind of choreography for the activities it is composed of. WSCI supports the 
definition of the following kinds of choreographies: 

• Sequential execution: The activities must be executed in sequential order. 

• Parallel execution: All activities must be executed, but they may be executed 
in any order. 

• Looping: The activities are repeatedly executed based on the evaluation of a 
condition or an expression. WSCI supports for-each, while, and repeat-until 
style loops. 

• Conditional execution: One out of several sets of activities is executed based 
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on the evaluation of conditions (switch) or based on the occurrence of an 

event (choice). 

2.1.3 Processes 

A process is a portion of behavior that is labeled with a name. The behavior 
described by a process can be reused by referencing its name. As such, the 
process is the WSCI unit of reuse. 

The way in which a process is used (or re-used) is by properly instantiating it. A 
process can be instantiated by: 

• Receipt of one or more messages that are defined as triggering the 
choreography described by the process. 

• Calling or spawning the process (see below). The respective Call or Spawn 
statements are explicitly shown in the interface. 

• Instantiating the process from within the service implementation. In this case, 
the actual instantiation of the process is not shown in the interface. 

In each of the above cases, the Web Service needs to be in a state where 
instantiating the process is allowed. Whether or not a process can be instantiated 
also differs on the type of the process. WSCI allows the definition of two types of 
processes: 

• Top-level processes: These processes are defined at the interface level and 
can be referenced from everywhere within the interface. 

• Nested processes: These processes are defined within complex activities. A 
nested process can be referenced only from within the complex activity that 
defines it. 

A process can be referenced using a Call or a Spawn statement: 

• The process is called: The behavior contained in the process will be 
executed, while the call waits for the called process to complete. This is very 
similar to calling a subroutine in a programming language. 

• The process is spawned: The behavior contained in the process will be 
executed in a parallel thread of control. The parallel thread can later be 
joined again. 

The ability to call processes introduces the concept of reuse into WSCI. The ability 
to spawn/join processes introduces the concept of parallel execution of activities 
into WSCI. 
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2.1.4 Properties 

Properties are introduced in WSCI as a modeling artifact used to reference a 
"value" within the interface definition. They are the equivalent of variables in other 
languages. The concept of properties, though, provides an additional layer of 
abstraction in WSCI. This layer eliminates dependencies between the interface 
definition and abstract message definitions (such as those defined by WSDL). 
Additionally, it allows referencing values instantiated by the service 
implementation. 

Properties can be used to avoid, within the interface definition, explicit references 
to abstract messages (or message parts) described in a service definition 
language (such as WSDL). This is accomplished in two ways: 

• For each incoming or outgoing message there is a property with the same 
value as the message content and with the same name as the abstract 
message name. The property is instantiated upon the receipt of the incoming 
message or the construction of the outgoing message, respectively. It has 
the same data structure as the abstract message. 

• A property may holda value obtained applying an expression to a part of an 
incoming message. The value of that property is obtained from any incoming 
message that includes the particular message part. The service should 
behave as if the value of the property is derived every time the service 
receives a message containing the specific message part. WSCI introduces 
the selector element (see Section 3.2 for more details), which defines how 
the value of a property is obtained from an incoming message. 

Properties may also be used to reference a value that is instantiated by the service 
implementation and could be used in the interface definition. Such properties are 
useful for specifying abstract conditions for loops and branches in message 
choreographies. 

Accordingly, properties can be used as: 

• An abstraction of the message itself; 

• A reference to a value established from a message part upon receipt of a 
message; 

• A reference to a value established by the service itself upon instantiation. 

A property is defined as a name-value pair. The name must be unique among all 
properties defined in the same scope. Properties do not need to be explicitly 
defined in order to be used. Consequently, their values are not explicitly restricted 
to any data type. WSCI does not prescribe any type system and values of 
properties may be of any data type. Properties are visible in the context in which 
they are instantiated including all its parent contexts, unless they are defined as 
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local properties to that context. 

Properties do not have to map to any concrete artifact implemented by the service; 
they are just a modeling artifact for WSCI and can be used whenever the 
description of the external behavior of the service requires referencing to "named 
objects". For this reason, a precise algebra for properties has not been specified. 

2.1.5 Context 

Context is a WSCI concept that describes the environment in which a set of 
activities is executed. Each context definition pertains to a particular set of 
activities, and each activity is defined in exactly one context definition. The context 
definition for top-level processes, when not present, is assumed to be empty. The 
context definition describes the environment for the set of activities it pertains to in 
terms of: 

• The set of declarations that are available to the activities; 

• The set of exceptional events that might occur during the execution of the 
activities, and the exceptional behavior triggered by those events; 

• The transactional properties associated with the execution of the activities. 

A context definition may contain two different kinds of declarations: local 
properties, and local process definitions. 

• Local properties are only available to the activities executing in this context. 

• Local process definitions designate exactly those processes that may be 
instantiated in this context. A local process can only be called or spawned 
from a context where the definition of the local process is visible (see the 
scoping rules for nested contexts below). Called/spawned processes 
execute in the context where they are defined. 

Context definitions may be nested to an arbitrary level. The scoping rule for nested 
contexts specifies that contexts see "outward" but neither "inward" nor "sideward". 
This means that an activity can refer to all local declarations defined in its own 
context and, recursively, in all of its parent contexts; this is referred to as the 
execution context for that activity. An activity cannot refer to local declarations 
defined in other contexts. Local declarations override local declarations with the 
same name in parent contexts. 

Web Services may implement the concept of context in many different ways; 
WSCI does not prescribe nor encourage any particular such implementation, but 
aims to describe in a neutral way how the presence of context affects the 
observable behavior of the Web Service. 
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2.1.6 Message correlation 

In WSCI, a conversation represents a message exchange between two or more 
services participating in a particular scenario. A service can be engaged in multiple 
conversations at the same time, with the same or with different services. The 
concept of correlation describes how conversations are structured and which 
properties must be exchanged to retain the semantic consistency of the 
conversation. A correlation is not limited to a single conversation between two 
participants; it can span multiple conversations between different participants. 

In the example presented in Section 5, a traveler exchanges messages with the 
travel agent. Initially the traveler will submit a chosen trip to the travel agent. The 
travel agent will, as response, return an itinerary. After that the traveler has a 
choice to change the proposed itinerary or make the reservation. This 
conversation between the traveler and the travel agent will be extended over a 
period of time. 

The travel agent can enter into many conversations with the same traveler. For 
example, the traveler can send multiple requests for creating different itineraries 
for different trips. A request to change a proposed itinerary sent from the traveler 
to the travel agent need to be associated with a particular conversation - one that 
deals with the specific itinerary. For each new trip a new conversation is initiated. 
Each conversation is related to a particular trip request. For each trip request the 
travel agent will return a unique itinerary identification number, which the traveler 
must use in all subsequent messages related to the proposed itinerary (e.g. 
change the proposed itinerary or make the reservation). 

In the example, we assume that the travel agent will contact the same airline 
company for each leg of the journey. Generally, it is possible that for different legs 
of the same journey a travel agent contacts different airline companies. In this 
case the travel agent engages in multiple conversations with different airline 
companies. These multiple conversations are considered as part of the larger 
conversation that relates to a single trip request. These (sub)conversations are 
distinguished by the itinerary identification number and the leg identification 
number. 

Correlation is the mechanism by which a message received by the service is 
associated with a particular conversation. Different conversations can be 
distinguished by correlation instances. The correlation instance is a set of 
properties' values. Each message that belongs to a conversation must be 
designated by a particular correlation instance. The correlation properties are 
communicated as part of messages exchanged in the actions. 

The service may implement the way in which it actually correlates messages 
belonging to the same logical conversations in multiple ways. WSCI aims to model 
this mechanism as seen from outside and it does not prescribe any 
implementation. 
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2.1.7 Exceptional behavior 

WSCI allows declaring exceptional behavior that is exhibited by a Web Service at 
a given point in a choreography. The declaration of exceptional behavior is part of 
the context definition, and associates exceptions with a set of activities that the 
Web Service will perform in response to those exceptions. It is possible to declare 
the occurrence of the following kinds of exceptions: 

• Receipt of a particular message that is considered as exceptional in that 
context. 

• Occurrence of a fault; this fault might correspond to the receipt of a WSDL 
fault message, or to the generation of a fault by the service itself. 

• Occurrence of a timeout. 

The occurrence of an exception causes the current context to be terminated after 
the activities associated with the exception have been performed; at this point, the 
behavior defined in the parent context is resumed. Thus, WSCI supports the 
concept of "recoverable exceptions" that do not cause the overall choreography to 
terminate (similar to the throw/catch concept in Java). However, the occurrence of 
a fault for which no exceptional behavior is defined causes the context to be 
terminated and the fault to be raised in the parent context. More abstractly, 
exception handling behavior defined in a parent context definition can act as the 
default behavior for all its children, and in reverse, exception handling behavior 
defined in a context definition can be used to override exception handling behavior 
defined in its parent. 

Exceptions are a WSCI modeling artifact designed to model the exceptional 
behavior exhibited by a Web Service at a given point of a conversation; they do 
not need to necessarily represent any "technical failure." 

2.1.8 Transactional behavior 

A context may be associated with a transaction. The transaction describes, from 
an interface perspective, the transactional properties of the activities that are 
executed in this context. Basically, the presence of transaction asserts that the set 
of activities is executed in an all-or-nothing manner, i.e. either the context 
terminates with no exception, in which case the transaction completes 
successfully, or the context terminates with an exception, in which case the effects 
of the activities executed so far are assumed to be rolled back by the private 
implementation of the service. 

A transaction may declare a set of compensation activities that will be executed if 
the transaction has completed successfully, but needs to be undone. Note that the 
compensation, being a part of the service interface, describes only the externally 
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observable activities required to undo the transaction; compensation does not 
describe how, from an implementation point of view, the transaction is undone. For 
instance, assume that a travel agent has performed a transaction to book a hotel 
room for a traveler. If this booking has to be undone because there is no available 
flight to that location, the travel agent will probably send a notification of the un- 
hooking to the traveler. In other words, the travel agent service describes its 
undoing of the "book hotel room" transaction by the compensation activity of 
sending the relevant notification to the traveler. 

A transaction is either atomic or open-nested. 

• Atomic transactions have no further inner structure. It is assumed that 
participants exchanging messages in the context of an atomic transaction 
rely on some kind of mechanism (e.g. CORBA OTS, JTS) to coordinate the 
outcome of the transaction, but specification of a specific such mechanism is 
outside the scope of WSCI. It is also outside the scope of WSCI to specify 
how the rollback of an atomic transaction is performed. 

• Open-nested transactions are composed of other transactions, which in 
turn may be atomic or open-nested. If an open-nested transaction needs to 
be rolled back, the currently open sub transactions within the open-nested 
transaction are rolled back first (recursively), and after that the already 
completed sub transactions are compensated for in reverse order of 
completion. 

2.1.9 Global Model 

As described previously, a WSCI interface models the externally observable 
behavior of a particular Web Service in a choreographed, long-lasting and stateful 
message exchange with one or more other services; thus a WSCI interface 
describes the view of the overall message exchange as seen from one participant. 
WSCI allows also describing a multi-participant view of the overall message 
exchange by means of the WSCI Global Model. 

The Global Model is described by a collection of interfaces of the participating 
services, and a collection of links between the operations of communicating 
services as described by a "static" service description language, such as WSDL. 
Links between operations indicate that the respective services will exchange 
messages across those links, i.e. there will be direct message flow(s) between 
those operations. Therefore, linked operations must be mirror images of each 
other. 

In most scenarios, the information provided by the global model allows to derive 
between which actions the messages will actually flow. This allows visual 
modeling, analysis, validation and simulation of the overall message exchange. 
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The Global Model operates at the logical level of "Service Type". Since actions 
specify the role on behalf of which the service acts, and since each WSCI action is 
related to an operation, it is possible to infer the source and target roles for any 
action described by a WSCI interface from the operation links defined in the Global 
Model. This is particularly important for granting a top-down mapping from the 
description of the collaboration view of the overall process. 

2.2 Extensibility 

Two kinds of extensions of WSCI are allowed: 

• Extensions introducing additional semantics that is not part of the normative 
WSCI specification, and 

• Extensions that are used to expand the interface and the model definitions 
and that do not change the semantics defined in the normative WSCI 
specification. 

There are three ways to accomplish the first type of extensions: 

• By adding new types of activities (e.g. a goto construct); this is achieved by 
using the substitution group mechanism introduced in [XML Schema 1 J. It is 
possible to define a new activity that uses wsci: activity as its substitution 
group (see Section 3.5.1 for more details about WSCI activity type). 
Substitution groups are not allowed in any other case. 

• By extending the semantics of actions; this is achieved by means of the 
extensibility features for the action element (see Section 3.4.1 ). For 
instance, the WSCI specification describes a normative extension, which is 
used to identify the service against which the action is performed (see 

Section 6). 

• By referencing a WSCI construct from within a document edited according to 
another specification; this is achieved by using strict naming rules that allow 
every process, activity, transaction and local property to be unambiguously 
referenced. For example, RDF can be used to annotate a WSCI interface 
definition with additional semantics. 

The second type of extensions is accomplished supporting extensibility elements. 
They are used to allow other (existing or future) specifications to extend the 
interface definition and the model definition by adding elements and/or attributes 
defined in namespaces different from WSCI namespace. These extensions do not 
change the semantics defined in the normative WSCI specification; they are 
optional and must use an XML namespace different from that of WSCI. The use of 
extensibility elements is restricted to specific tags identified by the informal syntax 
used in Section 3 (the {extension element} and {extension attribute} placeholders). 
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An extensible WSCI element can be extended by: 

• Zero or more attributes 

• And/or at most one element (with the exception of the action element which 
may be extended by more than one element) defined in a namespace 
different from WSCI namespace. 

The following table lists the extensible WSCI elements. 



WSCI 
element 



Extension attribute 

Supports the definition of 
selectors that use data types in 
type systems other than the 
XML Schema type system. 



Extension element 

Supports the definition of 
selectors that use expressions 
different from XPath expressions 
(e.g. XQuery). 



Supports operations defined by Supports definition of optional 
a service definition language normative or non-normative 
other than WSDL. semantics, e.g. locate services. 



Supports definition of 

<condit.ion> conditions using a language 
other than XPath. 



N/A 



Supports definition of operation Supports definition of advanced 



connectivity when a service 
definition language other than 
WSDL is used. 

Supports other information for 
the purpose of locating 
services. 



forms of operation connectivity, 
e.g. a definition providing the 
mapping of data types. 

Supports definition of locator 
mechanisms. 



3. Language Elements 

3.1 Introduction 



This section describes the WSCI language in detail. We first introduce some 
principles and notions that apply to all or most of the language elements. 

3.1.1 Terminology conventions 

Most of the concepts that are introduced by WSCI (such as process, context, 
transaction) have the following aspects: 
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• The actual WSCI syntax (the "syntactical" concept) 

• The use of the syntax in an instance of the WSCI schema (the "design time" 
concept) 

• An actual instance of the latter (the "run time" concept). 

In order to distinguish these aspects precisely, a consistent terminology will be 
used in the remainder of this document. This terminology can be explained using 
the concept of process. 

• The term "process construct" refers to the WSCI syntax. 

• The term "process definition" refers to an occurrence of the processeiement 
within a WSCI document. 

• The term "process instance" refers to the conceptual instance of such a 
definition. The term "process" is used sometimes instead of "process 
instance." 

3.1.2 The root element 

The WSCI top-level definitions (the interface, selector, correlation, and model 

elements) are nested inside the wsdi: definitions element. This should not be 
understood as if WSCI extended WSDL, but as a reuse of the wsdi: definitions 
element due to the fact that this element is convenient and WSDL is the only 
specification that, as of today, defines a container with the expected semantic. 
WSCI does not define a wsci : definitions element, envisaging that a neutral 
container will be defined for all specifications acting in the Web service area. 

Since WSCI reuses the wsdi: definitions and the wsdi: import elements, 
retaining their respective semantics, any tool needs to fully understand the syntax 
and semantics of these two WSDL elements in order to properly process WSCI. 

3.1.3 Documentation and naming 

Most of the WSCI constructs may be documented using the documentation 
element, and may be named using the name attribute. The semantics for these two 
syntax fragments will be explained here since it is the same wherever the 
fragments appear. 

The documentation element is used to provide any kind of useful and human- 
readable documentation. Usually, the documentation element will contain pure 
text, but it may also contain elements defined in a foreign namespace. A WSCI 
processor will not interpret the contents of the documentation element. 

The name attribute is required for correlation definitions, interface definitions, and 
the model element. It is optional for activity definitions, transaction definitions, fault 
definitions and the connect element. The value of the name attribute is a non- 
qualified name. It serves the purpose to reference the named entity from 
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elsewhere. For instance, correlation definitions are referenced in the 
correiateeiement, process definitions are referenced in the spawn or can 
elements, and interface definitions are referenced from within the global model. 

For each of the WSCI top-level constructs (interface, model, and correlation), the 
names of definitions of that construct form a scope of their own. This means, for 
instance, that the name of a correlation definition must be unique among the 
names of all correlation definitions within a given namespace, but need not be 
different from names of interface or model definitions in the same namespace. The 
same holds for names of interface definitions and model definitions. 

Within a process definition, WSCI only enforces name uniqueness for all local 
property declarations and nested process definitions within the same context 
definition (see also Section 3.5.4). 

3.2 Selector 

Selector is a mechanism to abstract a complex message into a set of properties of 
interest to the service interface. Each abstract message may consist of one or 
more logical parts associated with a data type from some type system, e.g. the 
XML Schema type system [XML Schema 1], [XML Schema 2]. Assuming that a 
message part is associated with a particular data type allows decoupling between 
a property and the part of the message from which the value of such property is 
obtained. The selector definition references a data type from some type system 
and not an abstract message definition thus allowing the value of a property to be 
obtained from any message that includes the particular message type. 

New message definitions can be added without affecting a previously defined 
selector. Also, the message structure can be changed (e.g. a part can be 
excluded); still the same selector definition can be used provided that the 
particular message part has not been changed. In this way selectors improve 
reuse and eliminate dependencies on abstract message definitions. They ensure 
that the interface definition is more resilient to changes. The same selector can be 
applied to any message that contains the message part associated with the same 
data type that is referenced in the selector definition. Selectors should be used 
when a property is derived from a message part using a non-trivial expressions 
(e.g. sum, count) or the property value can be obtained from any message that 
contains the message part associated with the particular data type. 

The selector definition specifies how the value of a property is obtained from an 
incoming message. The service should behave as if the value of a property is 
derived every time the service receives a message containing the specific 
message part. 

The syntax of the selector element is: 
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<seiector property = QName 

element = QName 

type = QName 

xpath = expression 

{extension attribute }> 

Content: (documentation?, 

{extension element}?) 
</selector> 

The property attribute specifies which property is instantiated (or modified) by the 
selector. The property is identified by its fully qualified name to allow the 
referencing of properties defined in any namespace. 

The element and type attributes are used to specify type references. The element 
attribute refers to an XML Schema element using a qualified name. The type 
attribute refers to an XML Schema simple type or complex type using a qualified 
name. These two attributes are mutually exclusive and optional. If both attributes 
are omitted an extension attribute must be used to reference a type system. The 
referenced type system must be different than the XML Schema type system. 
Exactly one type reference must be used. 

Note: XML Schema elements and types 
have different name scopes. It is valid to 
define an element with the same name as a 
complex type. Therefore two different 
attributes are defined in order to distinguish 
which definition is used. 

The xpath attribute provides an XPath expression [XPathJthat extracts a node-set 
from a message part in order to obtain the value for the property. This attribute is 
optional. If the xpath attribute is used, the content of the selector element may 
consist only of the documentation element. If the xpath attribute is omitted and the 
content of the selector element is empty or consists only of the documentation 
element, the complete message part is used to get the value for the named 
property. In this case the message part must be identified either by an XML 
Schema element or type definition. 

The selector element is an extensible element. An extension attribute can be 
used to define a selector that operates on a type system other than XML Schema 
type system. Zero or more extension attributes may be specified. An extension 
element can be used to define a selector that uses expressions different from 
XPath expressions (e.g. XQuery expressions). The selector allows at most one 
extension element to be used. 

If the selector element contains an extension element, the xpath attribute must be 
omitted. This extension declares how the value of the named property will be 
obtained from the message part. The message part may be identified either by an 
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element or type from the XML Schema type system or using any other data type. 

A selector definition is not limited to a specific interface definition. The selector 
element is a WSCI top-level element. 

Example. The value of the itinerary number property can be carried in different 
messages. Each of these messages has a message part of either simple type 
itineraryiD or element type itinerary. Consequently, two different selectors 
must be defined to obtain the value of that property. The accompanying types are 
provided below. 

<selector property = "tns : itineraryNo" 
type = "tns : itineraryiD" 
xpath = " . /text () " /> 

<selector property = "tns : itineraryNo" 
element = "tns : itinerary" 
xpath = "./itinerarylD/textO " /> 

<xsd: simpleType name = "itineraryID"> 

<xsd: restriction base = "xsd: string" ./> 
</xsd: simpleType> 

<xsd:element name = "itinerary" type = "tns : itineraryType" /> 

<xsd: complexType name = "itineraryType"> 
<xsd : sequence> 

<xsd: element name = "itineraryiD" type = "xsd: string" /> 
<xsd: element name = "leg" type = "xsd:leg" 

minOccurs = "1" maxOccurs = "unbounded" /> 

</xsd: sequence> 
</xsd: complexType> 

The following selector definition does not specify any expression. The complete 
message part of element type itinerary is used to get the value for property 

itinerary. This property has type itinerary. 

<selector property = "tns : itinerary" 
element = "tns : itinerary"/> 

The value of property legcount is calculated from any message having a message 
part of element type itinerary using the following selector: 

<selector property = "tns : legCount" 
element = "tns : itinerary" 
xpath = "count (. /leg) " /> 

The value of property legNo is obtained from messages, which include a message 
part of element type itinerary. The property contains identification numbers of all 
legs of a given itinerary. Complex type leg used in the definition of complex type 



http://www.w3 .org/TR/wsci/ 



5/8/2007 



Web Service Choreography Interface (WSCI) 1 .0 



Page 41 of 128 



itineraryType is provided belOW. 



<selector property = "tns:legNo" 

element = "tns : itinerary" 
xpath = " . /leg/legID" /> 



sd: complexType name = ' 
<xsd: sequence> 

<xsd:element name = 
<xsd: element name = 
type = ' 
<xsd: element name = 
<xsd:element name = 



leg"> 



"xsd: string" /> 



"legID" type = "xsd : string" 
"startTime" 
xsd: timelnstant" /> 
"startAirport" type = 
"destinationTime" 
"xsd: timelnstant" /> 
"destinationAirport" 
type = "xsd: string" /> 
<xsd:element name = "carrier" type = "xsd: string" /> 
<xsd:element name = "seat" type = "xsd: string" /> 
<xsd:element name = "cost" type = "xsd: float" /> 
<xsd: element name = "availability" type = " 
</xsd: sequence> 
xsd : complexType> 



3.3 Message Correlation 



The correlation mechanism is a general mechanism used in WSCI to describe how 
a Web service distinguishes between different conversations in which it 
participates. An informal description of the mechanism and its usage is provided in 

Section 2.1.6. 



WSCI defines two elements, correlation and correlate, that implement the 
correlation mechanism. The correlation element specifies a set of properties 
used for the purpose of defining the correlation identity. The correlate element 
(defined in Section 3.4.2) is used to associate an action with the correlation 
definition. 

3.3.1 Correlation 

The syntax of the correlation element is: 

<correlation name = NCName 
property = list of QName 
extends = QName> 
Content: (documentation?) 

</correlation> 

The name attribute holds the name of the correlation. This name must be unique 
among names of correlations defined in the same namespace. It is used to 
reference the correlation from a correlate element. The name attribute is 
mandatory. 
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The property attribute lists all the properties forming the correlation identity and 
used to identify a correlation instance. At least one property must be specified and 
no property can be repeated twice in the same correlation definition. The 
properties can be listed in any order. A property is referenced using a qualified 
name. 

A correlation can be defined as an extension of another correlation. In this case 
the correlation is a specialization of the extended correlation. It includes all 
properties that are part of the base (extended) correlation and adds one or more 
new properties. The base correlation is specified using the extends attribute. 
Additional properties are specified using the property attribute. The extends 
attribute is optional. 

A correlation definition is not limited to a specific interface definition. The 
correlation element is a WSCI top-level definition. 

Example. Two correlations are illustrated in this example: itinerarycorreiation 
and legcorreiation. The former correlation is based on the itinerary number 
property. The latter presents an extension of correlation itinerarycorreiation 
and is used to identify the conversation related to a specific leg of the itinerary. 
The legcorreiation correlation includes property itineraryNo that is part of the 
base correlation and adds one more property (i.e. the legNo property). 

<correlation name = "itinerarycorreiation" 

property = "tns : itineraryNo" ./> 
<correlation name = "legcorreiation" 

property = "tns: legNo" 

extends = "tns : itinerarycorreiation" /> 

3.4 Atomic behavior 
3.4.1 Action 

An action is an atomic activity that describes the manner in which the service uses 
an elementary operation in a context, in particular one involving the exchange of 
messages with other services. 

<action 

name = NCName 

operation = QNarne/ NCName 

role = QNarne 

{any attribute with non-wsci namespace }> 
Content: (documentation?, correlate* , call?, 

{any element with non-WSCI namespace}*) 

</action> 

When the action performs an operation defined by WSDL it uses the operation 
attribute. This attribute names the WSDL operation that is performed by the action. 
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The WSDL definition is referenced using the fully qualified name of the port type 
definition and the non-qualified name of the operation definition: 

Soperation =: portTypeName ' / ' operationName 

portTypeName =: QName 
operationName =: NCName 

For example, the value "tns : traveier/f inditinerary" refers to the WSCI 
operation "f inditinerary" that is part of the port type definition " traveler" that is 
defined in the same namespace as the WSCI interface. 

An action can be associated with one of the following types of WSDL operations: 

• One-way: The action performed by the service receives a message. A 
correlation should be used to associate the input message with the context in 
which the action occurs. 

• Request-response: The action performed by the service receives a 
message and sends a response back to the sender. A correlation should be 
used to associate the input message with the context in which the action 
occurs. 

• Notification: The action performed by the service sends a message to 
another service. No correlation is required. 

• Soiicit-response: The action performed by the service sends a message to 
another service and waits for a response. 

The role attribute associates a role name with the action. The role attribute is 
optional and takes the form of a fully qualified role name. The role attribute can be 
used to reference a role definition that is given by some other specification using 
the role's qualified name. An interface can perform actions on behalf of multiple 
roles. 

3.4.1.1 Example 

• The Traveler service indicates its intention to order the trip by performing the 
soiicit-response operation orderTrip defined as part of the port type 

definition tns:TravelerToTA as follows: 

<action name = "OrderTrip" 

role = "tns : Traveler" 
operation = "tns : TravelerToTA/OrderTrip" /> 

• The Traveler service exposes the request-response operation 
ReserveTickets defined as part of the port type definition tns:TravelerToTA in 
the following way: 
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Oction name = "ReserveTickets " 
role = "tns: Traveler" 

operation = "tns : TravelerToTA R lets"> 
<correlate correlation="def s : reservationCorrelation" 
instantiation^ "true" /> 

</action> 

• The following action references the request-response operation 
changeitinerary that the Travel Agent service exposes and that is defined 
as part of the port type definition tns : TAtoTraveier. Upon receipt of the 
request message, the service invokes a nested process for verifying seat 
availability (tns:verif y seats), and waits for it to complete before returning 
the response message. The request message is correlated to the instance of 

this process through the itineraryCorrelation. 

Oction name = "Changeitinerary" 
role = "tns:TravelAgent" 

operation = "tns : TAtoTraveler/ChangeItinerary"> 
<correlate correlation="def s : itineraryCorrelation" /> 
<call process = "tns :Verif vSeats"/> 
</action> 

3.4.2 Correlating the Action Context 

The correlate element is used to define a relation between an action within the 
interface definition and a correlation definition. The purpose of this relation is to 
exactly indicate which properties serve to correlate an incoming message with a 
particular conversation, or more formally to indicate a particular execution context 
in which the action should be performed. 

The syntax of the correlate element is: 

^correlate correlation = QName 

instantiation = (true | false) : false /> 

The correlation attribute references a correlation using fully qualified name. That 
allows referencing correlations defined in namespaces different from the 
namespace in which the interface is defined. This attribute is mandatory. 

The instantiation attribute is optional and may have either value true or false. If 
the attribute has value true properties forming the correlation identity will be used 
to identify the current execution context in all subsequent message exchanges; the 
properties forming the correlation identity will be instantiated in that context. If the 
attribute has value false (the default) the correlation properties are used to 
identify a previously established execution context in which the action should be 
performed. 

An action may specify zero or more correlate elements. These elements may have 
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different values for the instantiation attributes. If an action specifies, for instance, 
two correlate elements with the instantiation attributes having values false and 
true respectively, then: 

• the first correlate element (instantiation = false) specifies the correlation 
whose properties serve to identify the execution context in which the action 
should be performed 

• and the second correlate element (instantiation = true) specifies the 
correlation whose properties will be used to identify the same execution 
context in subsequent message exchanges. 

An operation references a correlation whenever the message conveyed by the 
operation contains all the properties that form the correlation identity (as defined 
by the selectors that apply to such message). This applies to any WSCI action. 

In order to associate an action with the proper context in which it is performed, the 
correlate element is used with the instantiation attribute set to false (or absent); in 
this case, the properties forming the correlation identity, must have been 
instantiated in that context before the correlation could be used in that way. 

The properties forming the correlation identity can be instantiated: 

• Upon the receipt of a message; this is expressed in the interface definition 
using the correlate element with the instantiation attribute having value true; 

• By means not described by the WSCI interface; WSCI would not describe, in 
this cases, how the instantiation happens and each service implementation 
could differ; WSCI only enforces the properties qualifying the correlation and 
their types. 

A context can be matched by means of an already established correlation only for 
operations that receive a message first, such as the WSDL one-way or request- 
response operations; the properties conveyed in the first message must be 
matched with properties that identify the context. The correlation identity can be 
conveyed, though, in any operation and individually in each message of that 
operation (both received and sent messages). Correlation properties can be 
instantiated by any operation that allows receiving of messages, such as a WSDL 
one-way, request-response and solicit-response operations. 

The correlate element is not allowed for actions that can only send messages 
(such as the WSDL notification operation). An action that performs an operation 
that begins with sending a message followed by receiving a message (such as the 
WSCI solicit-response operation) may only specify the correlate element with the 
instantiation attribute having value true; the correlation properties, in this case, 
must be conveyed by the incoming message. 
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An action performing an operation that begins with an input message and is not 
correlated is used as part of the process instantiation, and in cases where all 
instances of the process are allowed to receive the message and there is no need 
to correlate the message to a specific instance, for example a broadcast message, 
which should be received by all process instances. 

Example. This example shows a part of the behavior of the Traveler whose 
interface definition is completely specified in Section 5. The selected part of the 
behavior includes three actions: BookTickets, ReceiveTickets and 
Receivestatement. The first action performs a solicit-response operation and the 
last two actions perform one-way operations. In order to correlate the incoming 
messages (the confirmation of issued tickets and the statement) with the particular 
execution context (i.e. the context in which action bookTickets has been 
previously executed) the correlate elements are used. All three actions reference 
the same correlation bookingCorrelation. 

The first action specifies the correlate element with the instantiation attribute 
having value true. Therefore the incoming message must carry values of the 
correlation properties and the property values are used to identify the execution 
context in which action bookTickets is performed in the remaining message 
exchanges. 

<interface name = "Traveler"> 

<process name = "PlanAndBookTrip"> 

Oction name = "bookTickets" 

role = "tns : Traveler" 

operation = "tns : TravelerToTA/bookTickets"> 
<correlate correlation = "def s : bookingCorrelation" 
instantiation = "true"/> 

</action> 
<all> 

Oction name = "ReceiveTickets" 
role = "tns : Traveler" 

operation = "tns : TravelerToAirline/ReceiveTickets"> 
<correlate correlation = "def s :bookingCorrelation"/> 
</ac.tion> 

Oction name = "ReceiveStatement" 
role = "tns: Traveler" 

operation = "tns : TravelerToTA/ReceiveStatement"> 
<correlate correlation = "def s : bookingCorrelation" /> 
</action> 
</all> 

</interface> 

3.4.3 Calling a process from within an action 
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An action that handles a request-response message exchange can perform an 
arbitrary set of activities before it completes by calling another process. The call 
element is used to indicate the activities that would occur while the action is being 
performed by the service. 

<call 

process = NCName> 
Content: (documentation?) 

</call> 

An action can perform an arbitrary set of activities only if the operational semantics 
indicate that such activities must occur between the beginning and end of the 
action. The call element is allowed when performing the WSDL request-response 
operation, but is forbidden for all other WSDL operations. 

Since an action is an atomic activity, the process is invoked and completed before 
the action completes. If a fault occurs while performing that process, the action will 
also fault. 

3.4.4 Extensibility of the action element 

The action element is an extensible element. The action element can refer to 
operations defined in a specification other than WSDL using extension attributes. 
Extension attributes are defined in any namespace other than WSCI. The 
operation attribute and extension attributes are mutually exclusive. 

The action element can specify additional semantics pertaining to the operation 
being performed. Additional semantics are expressed using extension elements 
that are defined in any namespace other than WSCI. 

A WSCI processor may optionally process additional semantics in one or more 
namespaces. The manner in which such semantics are processed is outside the 
scope of this specification. 

This specification does include one such extension that expresses the manner in 
which an action can identify a peer service against which an operation is 
performed. This extension consists of the locate elements which are defined later 
on in this specification. Both elements are defined in the WSCI/locate namespace 
(see Section 6.1) 

3.5 Choreography Description 

Atomic activities are the elementary units of the interface definition. An atomic 
activity is one that cannot be further decomposed and is performed in an all-or- 
nothing manner. The most common atomic activity is action. This activity will 
perform a single operation, e.g. receiving a message (one-way operation) or 
sending a message and waiting for a reply (solicit-response operation). 
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Complex activities are containers for sets of activities and define rules for 
coordinating the order in which activities are performed from within the activity set. 
Unlike atomic activities, complex activities can be decomposed into atomic and 
complex activities. 

3.5.1 Activity 

Interfaces define Web Services as performing activities of varying complexity. The 
definition of services as performing activities enhances the definition of services as 
performing operations by adding the proper context in which an operation is said 
to occur, and allowing operations to be associated over space and time. While 
operations are stateless in nature, activities are stateful. 

As a result the interface can define a complex behavior that can include complex 
interactions involving multiple operations and services, transactional behavior and 
exception handling, and the dynamic establishment of links across services. 

Similarly, an activity may be as simple as a one-way operation performed against 
one other service, or as complex as multiple message exchange with a set of 
services. 

When two or more activities perform in the same context they often use the 
context as a container for shared properties. The activities can establish a relation 
to each other by appearing to read and write properties in that context. For 
example, an activity that sends a message can depend on a property established 
from a message received by a previous activity. 

Contexts are also used to distinguish between multiple instances of the same 
activity. An activity not only establishes its dependency on a previous activity 
occurring in the same context, but on a specific instance of such activity. This form 
of continuity allows us to define complex stateful interactions involving the 
exchange of multiple messages with the same or different peer services. 

A context must be established before the activity is performed. For that reason the 
context is not defined by the activity itself but ahead of the activity definition. 

3.5.2 Activity Set 

Since contexts are often used to establish a relation between two or more 
activities, we allow a context definition to be used by a set of activities. An activity 
set defines a set of activities together with the context in which they execute. The 
syntax for an activity set is: 

Content: (context?, {any activity}+) 

An activity set can include any type of activity element. This includes all activities 
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defined in this specification. In addition, activities defined in other specification can 
be used as long as they are defined in a namespace that is other than WSCI and 
use the wsci: activity abstract element as their substitution group. 

Note that an activity set is not an element or a complex type, but rather a model 
group. It is used as part of the content of various elements, always in the form 
depicted above. 

The context element is optional. If absent, we treat it as if the context definition as 
empty. 

All activity elements are based on a common type definition with the syntax: 

<{ activity type} 

Content: (documentation?) 



The optional name attribute provides the non-qualified activity name to distinguish 
the activity from any other activity defined in the same context. If used, the activity 
name must be different from any other entity defined in the same context, 
including other activities, properties, nested processes, etc (see Secti on 3.5.4 for 
more details about contexts). 

An activity is always performed within some context. The definition of a context 
makes the distinctive difference between stateless operations and stateful actions. 
The context in which an activity is performed is referred to as the activity's current 
context. 

3.5.3 Complex Activity 

A complex activity is any activity that contains one or more activity sets. The 
complex activity defines the rules for determining which activity set will be 
performed, determining the number of times the activity set will be performed, and 
determining the order in which the activities will be performed from the set: 

• The complex activity ail operates on a single activity set and performs the 
activity set exactly once; the activities can be performed in non-sequential 
order. 

• The complex activity sequence operates on a single activity set and performs 
the activity set exactly once in sequential order. 

• The complex activity choice selects one activity set based on a triggered 
event, and performs that activity set exactly once in sequential order. 

• The complex activity foreacn operates on a single activity set and performs 
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the activity set zero or more times, performing the activities in sequential 
order in each iteration. 

• The complex activity switch selects one activity set based on a condition, 
and performs that activity set exactly once in sequential order. 

3.5.4 Context 

Just like activities, contexts are composed recursively. An activity is performed in 
the current context, as defined by the activity set in which the activity appears. 
When that activity set is contained in another activity, that parent activity provides 
a parent context. The current context encompasses the parent context and all its 
parent contexts recursively. 

In fact, the current context is a combination of the parent context and any local 
declaration made in that context. A local declaration is a declaration made in the 
current context that hides any entity with the same name in the parent context. A 
local declaration can be used to confine an entity to the current context, or to hide 
changes that could occur in the current context from affecting any parent or sibling 
context. 

The syntax for a context definition is: 

<context> 

Content: ((process | property) *, exception?, 
transaction?) 

</context> 

• Property: Declaring a property as local to a context assures that any 
changes to the value of that property (as a result of activities occurring in that 
context) do not affect the value of that property in any parent context. 

• Exception: Declaring an exception behavior as local to a context assures 
that that definition will be honored in case of an exception occurring in that 
context, without changing the definitions prescribed for a parent context. 

• Process: Declaring a process as local to a context (also known as nested 
process) assures that this particular process definition is not available in the 
parent or sibling context, and further allows the nested process to establish a 
relation with any other activity or process occurring in the same context. 

• Transaction: Declaring a transaction as local to a context assures that all 
activities occurring in that context and only these activities are performed as 
part of that transaction. 

Properties and processes declared within a given context must use unique names. 
It is an error for two property declarations, process declarations or a property and 
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process declaration in any given context to have the same fully qualified name. 

A context is established before performing the first activity in the activity set and is 
discarded after performing the last activity in that activity set. A context is not 
established until it has not been determined that at least one of the activities in the 
activity set are to be performed. The declarations of a context are available to the 
set of activities while the context is active, i.e. between establishing and discarding 
the context. 

The syntax for a local property declaration is as follows: 

<property 

name = QName 
select = XPath> 

Content: (documentation?, value?) 

</property> 

<value> 

Content: {mixed} 
</value> 

The name attribute provides the property name. The property name is a fully 
qualified name since it is permissible to use properties defined in a namespace 
other than the namespace used for the interface definition, in particular properties 
that are shared across many interface definitions. If no other element or attribute is 
used, the property value is obtained from the property with the same name in the 
parent context. 

The select attribute is an XPath expression. If used, the expression is evaluated 
to arrive at the value of the property. This attribute is used to establish a dynamic 
value that can differ across instances of the same context. 

The value element is a contained or mixed contents. If used, the specified value is 
used as the value of the property. This attribute is used to establish a static value 
that is identical across instances of the same context. The value can include 
elements in any namespace and its content need not validate. 

The select attribute and value element are mutually exclusive; it is an error to use 
both at the same time. In either case, changes to the named property that occur 
within the context in which it is defined do not affect any property with the same 
name in any parent or sibling context. 

3.6 Choreography Elements 

3.6.1 All 

The ail activity is a complex activity. If performs all the activities within the activity 
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set in non-sequential order, possibly in parallel. 

<all 

name = NCName> 

Content: (documentation?, context? , (any activity}*) 

</all> 



The choice activity is a complex activity that selects one activity set from e 
collection of two or more activity sets based on the first event triggered. 

<choice 

name = NCName> 

Content: (documentation?, 

(onMessage | onTimeout I onFault) {2, n} ) 

</choice> 
<onMessage> 

context?, {any activity }+) 

</onMessage> 

<onTimeout 

type = (duration I dateTime) : duration 
reference = QName> 

Content: (documentation? , context ? , {any activity}-!-) 
</onTimeout> 

<onFault 

code = QName> 

Content: (documentation?, context?, {any activity}-!-) 

</onFault> 



The choice activity must specify two or more mutually exclusive events. 

Events that may be defined with a choice are receipt of a message, the raising of a 
fault, and the elapsing of a time-out. 

If two or more events overlap with each other the interface is considered 
ambiguous. 

3.6.2.1 Example 

In this example (taken from Section 5.4.3.2 ), the Airline Reservation System 
describes how it waits for one of two operations to be performed. Either booking is 
requested (by means of the Bookseats operation), or the reservation is cancelled 
(by means of the canceiReservation operation). In the first case, the service will 
proceed by issuing the tickets and sending them to the Traveler. In the second 
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case, the service will proceed by compensating for the reservation transaction. 

<choice> 

<onMessage> 

<action name = "Perf ormBooking" 
role ="tns: Airline" 

operation = "tns : AirlineToTA/BookSeats"> 
<correlate correlation="def s : reservationCorrelation"/> 
</action> 

<action name="SendTickets" 
role ="tns : Airline" 

opera tion=" tns : AirlineToTraveler/SendTickets"/> 
</onMessage> 

<onMessage> 

<action name = "ReceiveCancellationRequest"> 
role ="tns:Airline" 

opera tion=" tns : Air lineToTA/CancelReservat ion" > 
<correlate correlation="def s : reservationCorrelation" /> 
</action> 

<compensate name = "CompensateReservation" 

transaction = "tns : seatReservation" /> 

</ onMessage> 
</choice> 

3.6.2.2 Message Event Handler 

The onMessage event handler responds to an incoming message. The initial action 
defines the event that triggers this event handler. If this atomic activity is 
performed successfully, the activity set is performed. If this atomic activity faults, 
the choice activity will fault with the same code. 

The initial action is allowed to perform the WSDL one-way or request-response 
operation, but is forbidden to perform all other WSDL operations. 

3.6.2.3 Timeout Event Handler 

The onTimeout event handler responds to a time-out event. The property attribute 
is the name of a property, which holds the time-out value. The type attribute 
specifies the type of the time-out value as either dateTime or duration: 

• dateTime The named property specifies the date/time instant at which the 
time-out event occurs. The XML Schema datatype dateTime can be used to 
specify a date/time instant value. 

• duration The named property specifies the time duration relative to a 
reference time. The XML Schema datatype duration can be used to specify a 
duration value. 
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The default reference time for a time-out of type duration is the time instant at 
which the choiceactivity was started. The time-out date/time instant is calculated 
by adding the duration to the reference time. 

The reference attribute is used to specify a different reference time. This attribute 
can be used only if the time-out type is duration. The referenceattribute is the 
name of a property that holds a reference date/time instant. The XML Schema 
datatype dateTime can be used to specify a date/time instant value. 

The reference attribute can refer to the start or end time of an activity, transaction 
or process using the suffix @start or @end, respectively. The referenced entity 
must be performed in the same or parent context in which it is referenced. 

The syntax for the reference attribute is: 

reference =: property | entityStart | entityEnd 
property =: QName 
entityStart =: QName ' @ start * 
entityEnd =: QName' Send* 

3.6.2.4 Fault Event Handler 

The ontauit event handler responds to a fault. The code attribute specifies the 
fault code. If used, the event handler only responds to a fault with this code. If 
absent, the event handler responds to all faults for which no other event handler is 
specified. 

The choice activity defines the behavior when a fault occurs in the service, while 
waiting for another event to occur, e.g. receipt of a message. Faults that occur 
when performing an action, e.g. a WSDL solicit-response operation, and faults that 
occur when performing activities (see the fault activity) are caught by exception 
event handlers. 

3.6.3 Behavior 

The first event to occur will trigger the corresponding event handler and perform 
the activity set specified by that event handler. All other event handlers will be 
ignored. 

The event handlers specified by choice may overlap with event handlers specified 
by exception and will take precedence in case of an overlapping event. 

3.6.4 Foreach 

The foreach activity is a complex activity that performs all the activities within the 
activity set repeatedly, once for each item in a pre-selected list. 
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<f oreach 

name = NCName 
select = expressions 

Content: (documentation?, context?, {any activity}+) 

</f oreach> 



The select attribute specifies an expression that evaluates to a list of zero or more 
items. This attribute is an XPath expression. The item list is selected before the 
activity set is performed. The activity set is repeated once for each item in the 
selected list in the same order in which the list items are constructed by the XPath 
expression, or zero times if the list is empty. 

For each iteration the value of the current item is held in the property wsci : current 
which is local to the context in which the activity set is performed. 



3.6.5 Sequence 

The sequence activity is a complex activity that performs all the activities within the 
activity set in sequential order. 



name = NCName> 

Content: (documentation?, context?, {any activity}+) 
</sequence> 



3.6.5.1 Example 

In this example (taken from Section 5.4.1.2), the Travel Agent service describes 
how some operations must be performed in sequential order; first, the Travel 
Agent indicates an intention to cancel the reservation by sending a cancellation 
request to the airline. It, then, waits for receipt of a cancellation confirmation from 
the airline. Last, it notifies the traveler that the reservation has been cancelled. 



''soqr.e nce> 

<action name = "CancelReservation" 
role = "tns : TravelAgent" 

operation = "tns : TAtoAirline/RequestCancellation"/> 

<action name = "ReceiveCancellationNotif ication" 
role - "tns: TravelAgent" 

operation = "tns : TAtoAirline/AcceptCancellation"> 
<correlate correlation = "defs : reservationCorrelation"/> 
</action> 



<action name = "NotifyOf Cancellation" 
role = "tns : TravelAgent" 

operation=" tns : TAtoTraveler/Notif yOf Cancellation" /> 
</sequence> 



3.6.6 Switch 
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The switch activity is a complex activity that selects one activity set from a 
collection of one or more activity sets based on the evaluation of one or more 
conditions. 

<switch 

name = NCName> 

- i ation?, case+, default?) 

</switch> 
<case> 

Content: (documentation?, condition, 
context?, { any activity}*) 

</case> 
<default> 

Content: (documentation? , context? , {any activity}*) 
</def ault> 

<condition 

{extension attribute }> 

Content: {expression} 
</condition> 

The case element selects an activity set based on the truth-value of a condition. All 
cases are mutually exclusive. 

The order in which case elements are specified is important. The conditions are 
evaluated in that order, the first condition to be met will cause the activity set to be 
performed ignoring all other cases. 

The default element selects an activity set in the event that no other condition has 
been met. If absent and no condition is met the switch activity completes without 
executing any activity. 

The condition element specifies a condition that must evaluate to a Boolean 
value, as defined by the XPath specification. The condition is evaluated in the 
context in which the switch activity is performed. Conditions are most commonly 
expressed using the XPath language. 

The condition element is an extensible element. If an extension attribute is used 
the type of expression and the manner in which it is processed depends on the 
extension attributes. Extension attributes are defined in any namespace other than 
WSCI. 

3.6.6.1 Example 

In this example (taken from Section 5.4.2.2), the condition is abstract and does not 
indicate the internal logic employed by the Traveler, as this may differ across 
implementations. The Traveler selects between canceling an itinerary and 
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reserving tickets. 



cch> 



<conciition>tns : cancelItinerary</condition> 
<action name = "Cancelltinerary" 
role = "tns : traveler" 

operation = "tns : TravelerToTA/Cancelltinerary" /> 

</case> 
<default> 

<action name = "ReserveTickets" 
role = "tns : traveler" 

operation = "tns : TravelerToTA/ReserveTickets"/> 
</default> 
</switch> 



3.6.7 Until 

The until activity is a complex activity that performs all the activities within the 
activity set repeatedly, one or more times, based on the truth value of a condition. 

<until 

name = NCName> 

Content: (documentation?, condition, 
context?, {any activity }+) 

</until> 

The activity set is performed at least once. The condition is evaluated after each 
completion of the activity set. If false the activity set is performed again, otherwise 
the until activity completes. 

Refer to the switch activity for the definition of the condition element. 

3.6.8 While 

The while activity is a complex activity that performs all the activities within the 
activity set repeatedly, zero or more times, based on the truth-value of a condition. 

<while 

name = NCName> 

Content: (documentation?, condition, 
context?, {any activity } +) 

</while> 

The condition is evaluated repeatedly before the activity set is performed. If true 
the activity set is performed, otherwise the while activity completes. Refer to the 
switch activity for the definition of the condition element. 

3.7 Other activities 
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3.7.1 Delay 

The delay activity is an atomic activity expressing a time interval. 

<delay 

name = NCName 
property = QName 

type = (duration | dateTime) : duration 
reference = re£'Type> 
Content: (documentation?) 
</delay> 

This activity completes after the specified delay. It may complete prior to the 
specified delay if an exception occurs in the context in which the delay activity is 
defined, e.g. a fault or a message received by an exception event handler. 

The property, type and reference attributes specify the delay as either time 
duration or a date/time instant, and are used as with the onTimeout event handler 
(see there) with the following difference: the default reference time for a delay of 
type duration is the time instant at which the delay activity started. 

3.7.2 Empty 

The empty activity is an atomic activity that does nothing. 

< empty 

name = NCName> 

Content: (documentation?) 
</empty> 

The empty activity can be used in places where an activity must appear, but the 
behavior of the interface does not reflect any observable activity (for instance 
when performing an internal operation). 

3.7.3 Fault 

The fault activity is an atomic activity that triggers a fault in the current context. 

<fault 

name = NCName 
code = QName > 
Content: (documentation?) 

</fault> 

The code attribute specifies the fault code. The fault will trigger the matching 
onFauit exception event handler in the same context in which the fault occurs. 

If the fault is not handled by any exception event handler defined in the current 
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context, or in any parent context, the process will complete with that fault code. If 
the process is called by an action, e.g. when performing the WSDL request- 
response operation, the action will complete with that fault code, returning a fault 
message to the sender. 

3.8 Composition and Re-use 

WSCI also supports the definition of interfaces that express complex processes, 
and can, in essence, handle multiple 'threads' of execution simultaneously. 
Multiple parallel 'threads' with differing choreographies are specified with the 
'spawn/join' construct. 

Those with the same choreography are specified implicitly with the 'correlation' 
construct. Correlation specifies the set of properties that collectively allow the 
service provider to connect any incoming message to the right 'instance' of the 
choreography. 

Furthermore, each action/activity can be described as an inline definition in a 
parent activity or process, or it can be reused by defining it as a process and 
referring it with the call activity. 

3.8.1 Process 

A process is a special type of activity that establishes its own context of execution. 
As such it can serve as a top-level definition that is directly accessible for 
instantiation; a process does not need a pre-established context to execute in, but 
it instantiates its own context as it is instantiated. 

A process defines one activity set that is performed exactly once and all activities 
in that activity set are performed in sequential order. A process can be instantiated 
from another process by spawning or calling it. A process can also be instantiated 
from another service by sending it a message, when the process is defined as 
being instantiated upon receipt of a message. 

<process 

name = NCName 

instantiation = message I other : messaged 
</process> 

The name attribute provides the non-qualified process name to distinguish the 
process definition from any other process defined in the same interface or context. 

The instantiation attribute indicates whether the process is instantiated in 
response to a message or by other means. 

If the value of the instantiation attribute is message, the process is instantiated 
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upon receipt of a message. The process definition must begin with an activity that 
responds to an incoming message, e.g. an action that references a WSDL one- 
way or request-response operation. 

The process definition is allowed to begin with an ail activity that includes only 
such actions. In this case the process will be instantiated upon receipt of all 
messages at once. It is intended that all actions will complete upon instantiation of 
the process. 

The process definition is allowed to begin with a choice activity that consists only 
of onMessage event handles that begin with such an action. In this case the 
process will be instantiated upon receipt of any one message. It is intended that 
exactly one action will complete upon instantiation of the process. 

If the value of the instantiation attribute is other, the process must be 
instantiated by some other means. 

It is possible to instantiate such a process using the spawn and can activities, but 
only from other processes defined in the same interface. Other means of 
instantiation are possible, but not covered by the WSCI specification. 

When a process is instantiated it establishes the context and performs all the 
activities in the activity set in sequential order. In that respect a process definition 
is similar to the sequence activity, but it does not have to be contained within an 
activity set. 

If the process definition appears within the interface element, we consider it a 
top-level process definition. A top-level process is performed in a context that is 
independent of any other context. 

If the process definition appears within the context element, we consider it a 
nested process definition. A nested process is performed in the context in which it 
is defined. Unlike a top-level process, the nested process uses the context in 
which it is defined as its parent context, and may share the same properties as its 
parent process. A nested process may require local property declarations to 
isolate itself from any other activity performed in that context. 

When instantiation type is other, a nested process may be instantiated from 
any activity occurring in the same context in which it is defined, a child context, or 
another nested process in the same context. When instantiation type is message, 
a nested process may be instantiated only as part of an instance of that context. 

A nested process may complete after all activities defined in the same context 
have completed. For that reason, event handlers that are defined in that context 
do not react to any exceptions that occur in the nested context. The parent context 
may use the join activity or a transaction to establish such a relationship. 
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3.8.2 Call 

The can activity is an atomic activity that instantiates a process and waits for it to 
complete. 

<call 

name = NCName 

process = NCName> 

Content: (documentation?) 
</call> 

The named process definition must be visible in the current context in which the 
call activity is performed. 

The called process is instantiated in the same context in which it is defined. This 
context may be different from the context in which the call activity is performed. 

The call activity waits until the instantiated process completes. If the process 
faults, the call activity will fault with the same code. The call activity does not 
directly affect any call, spawn or join activity that occurs in the same or different 
context. 

3.8.3 Spawn 

The spawn activity is an atomic activity that instantiates a process. 

<spawn 

name = NCName 
process = NCName> 
Content: (documentation?) 

</spawn> 

The process attribute names the spawned process. The named process definition 
must be visible in the current context in which the spawn activity is performed. The 
spawned process is instantiated in the same context in which it is defined. This 
context may be different from the context in which the spawn activity is performed. 
The spawn activity creates a new process instance and completes. It does not wait 
for the spawned process to perform any activity. 

3.8.4 Join 

The join activity is an atomic activity that waits for instances of the spawned 
process to complete. 

< j oin 

name = NCName 

process = NCName> 

Con ten t : (documentation? ) 
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</ j oin> 

The process attribute names the process to join. This activity waits for the 
completion of all instances of the named process that were spawned in the current 
context and have not completed yet. This includes instances that were instantiated 
by a message, by the spawn activity, or by some other means. Instances that were 
instantiated by the call activity cannot be joined. If no instance exists, or all 
instances have already completed, the activity completes. 

3.9 Exception Handling 

Activities define the expected behavior of a service. Unexpected behavior is 
captured by defining exception handling. Exception handling is associated with a 
particular activity set by defining it as part of the context in which the activity set is 
performed. Since contexts are composed hierarchically, exception handling 
behavior defined in one context can be used to mask exception handling behavior 
defined in a parent context, and in reverse, exception handling behavior defined in 
a parent context can act as the default behavior for all child contexts. 

3.9.1 Exception 

Exception handling is associated with a particular activity set by defining it as part 
of the context in which the activity set is performed. Since contexts are composed 
hierarchically, exception handling behavior defined in one context can be used to 
mask exception handling behavior defined in a parent context, and in reverse, 
exception handling behavior defined in a parent context can act as the default 
behavior for all child contexts. 

Exception handling behavior is defined using the exception element: 

<exception> 

Content: ( (onMessage | onTimeout | onFault){+}) 
</exception> 

The exception handler must specify one or more event handlers. An event handler 
defines the event and the activity set to perform, should that event occur. 

Events are mutually exclusive; if two or more events overlap with each other, or if 
the onMessage event overlaps with an action in the same or child context, the 
interface is considered ambiguous. 

The onMessage, onFauit and onTimeout event handlers are similar to those used 
for the choice activity (see there), with the following differences: 

• onMessage: If this atomic activity faults, the exception handler will fault with 
the same code. 
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• onTimeout: The default reference time for a time-out of type duration is the 
time instant at which the context was established. The time-out date/time 
instant is calculated by adding the duration to the reference time. 

• onFauit: The exception event handler will response to a fault occurring while 
performing an action in that context, e.g. a WSDL solicit-response operation. 
The fault activity can be used to force the presence of a fault not triggered by 
the execution of an action. If a fault is not caught by an exception event 
handler within the context in which it occurs, the fault will be propagated to 
the parent context. If the fault is not caught in any parent context, the 
process will complete with that fault code. If the process is called by an 
action, e.g. when performing the WSDL request-response operation, the fault 
will be returned to the sender. 

The first event to occur will trigger the corresponding event handler and perform 
the activity set specified by that event handler. All other event handlers defined in 
the same exception handler will be ignored. However, event handlers defined in a 
parent context are still in effect and may respond to exceptional events occurring 
while performing any event handler in the child context. 

The activities performed by the activity set are completed before the activities 
defined in the event handler are performed. 

The service must wait until it can either complete in-progress atomic activities, or 
cancel such activities, behaving as if they never occurred. It is an error to behave 
as if an atomic activity has partially completed. 

The service is able to partially complete an in-progress complex activity by 
completing all in-progress activities in its activity set and not performing any further 
activities in the activity set. The activity set context is discarded before the 
complex activity completes. The context in which the exception handler appears is 
discarded only after the activity set specified by the event handler has completed. 

3.10 Transactional behavior 

3.10.1 Transactions 

WSCI Transactions are used to model the behavior of a Web service asserting 
that a certain number of activities should be treated as a single unit of work; a Web 
service uses a WSCI transaction to communicate to other services its ability to 
either completely execute those activity or to restore the consistent state prior to 
the execution. 

A Web service may, also, use a WSCI transaction to communicate to other 
services its ability to perform the transactional block as part of a distributed 
transaction protocol. 
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3.10.1.1 Atomic Transactions 

A WSCI Atomic transaction is used to model an ACID transaction. Atomic 
transactions assure that all activities performed as part of the transaction will 
behave as a single unit of work. If the transaction cannot complete successfully, it 
will rollback to the state before the beginning of the transaction. 

Individual activities can be atomic, but there is no guarantee that all activities will 
complete successfully or rollback. The atomic transaction gives an all-or-nothing 
guarantee to any activity set that is performed as part of the transaction. 

Atomic transactions require resource locking. Resource locking can be disruptive if 
locks are maintained for a long period of time, as such, atomic transactions are 
only recommended for short-lived transactions. 

3.10.1.2 Open Transactions 

Open (Nested) transactions relax the isolation requirement of atomic transactions 
and allow arbitrary levels of nesting. With open transactions, resources are 
acquired for short periods of time and then released, typically by using a 
combination of nested open and atomic transactions. As such, open transactions 
can be used for long-lived transactions that cannot complete in a short time span. 

Open transactions allow activities to progress from one consistent state to another, 
making each change permanent and durable immediately upon completion of the 
activity. As a result, open transactions are more resilient to system failures and are 
useful in supporting long-lasting transactions. 

In the event of a system failure, an atomic transaction will rollback and must be 
retried. This approach is practical for transactions that can be performed in a short 
time period. In contrast, an open transaction will continue to perform its activities 
past a point of failure, and can be used for transactions that span an arbitrary time 
period. 

Open transactions require additional work in order to perform backward recovery, 
since the effects of the transaction cannot be reverted automatically. Often, this is 
accomplished by compensating for the nested transactions in order to rollback the 
parent transaction. 

Open transactions attempt to provide an all-or-nothing guarantee, but may not 
achieve full atomicity. Unlike atomic transactions, open transactions can be used 
in cases where the effects of a transaction cannot be reverted completely as part 
of a rollback or compensation. 

3.10.1.3 Compensation 
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An open transaction made of multiple activities and transactions, rolls back by 
reverting their effects. Whilst rollback occurs while the transaction aborts and 
cancels the effects of the transaction that has not yet completed, compensation 
occurs after the transaction completes and reverts the effects of the completed 
transaction. 

Compensation defines the logic for reverting the effects of a completed activity or 
transaction. 

A parent transaction fulfills its responsibility to compensate by providing its own set 
of activities, and by invoking the compensating activity set of a nested transaction 
using the compensate activity. 

In WSCI, the transaction definition can specify which activities will occur when it is 
compensated; these activities will be performed when invoked by the compensate 
activity. 

The compensating activities (after completion) are defined separately from the 
rollback (before completion); both are defined together with the transaction as part 
of the same WSCI context. 

A transaction instance can only be compensated once. 
3.10.1.4 Behavior 

Any activity set may be assigned transactional behavior by defining its context 
using the transaction element. All activities executed in that context, including 
atomic and complex activities and nested processes instantiated in that context, 
are performed as part of that transaction. The activity set cannot complete until the 
transaction has completed or aborted. 

If a context defines its own transaction and has a transactional parent context, that 
transaction is a nested transaction. The parent-child relationship of contexts 
transfers to a nested relationship between the transactions. Similarly, a transaction 
is nested if it is defined as part of a nested process that itself is defined in a 
transactional context. 

Both atomic and open transactions can be nested in an open transaction. It is an 
error to nest any transaction within an atomic transaction, since protocols that 
support atomic transactions do not support nesting of transactions. 

A transaction can initiate recovery by catching an exception within an exception 
event handler that is defined in the transaction context. The transaction event 
handler indicates which activities will occur when the transaction attempts to 
rollback. The semantic of rollback is only applied to an event handler if used in a 
transactional context. 
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The compensate activity is used to compensate for a transaction. This activity can 
only be performed in a parent context of the completed transaction; the 
compensation behavior is executed in the context where the completed 
transaction executed. 

The compensation activity set may reference local property declarations made in 
the compensation context and local property declarations made in the transaction 
context. All other properties are referenced in the parent context of the transaction. 

A nested transaction can complete or abort independently of the parent 
transaction. If the nested transaction has completed and the parent transaction 
aborts, it is the responsibility of the parent transaction to compensate for the 
nested transaction. 

A parent transaction is not allowed to complete until all nested transactions either 
complete or abort. A nested process that is defined in a transactional context (or 
any of its child contexts) is instantiated as part of that transaction. A transaction is 
not allowed to complete until all activities performed in that transaction have 
completed, including any nested processes defined in the transaction context. A 
nested process is defined in a transactional context to indicate that a fault of the 
nested process causes the transaction to abort. 

3.10.1.5 Syntax 

The syntax for a transaction definition is: 

•transaction 

name = NCName 

type = atomic | open : atomic 
retries = QName> 
Content: (compensation?) 
</transaction> 

The name attribute provides the transaction name. The type attribute specifies the 
transaction type. The default, when the type attribute is missing, is to describe an 
atomic transaction. 

The retries attribute is a property that specifies the number of times the 
transaction can be repeated until it completes. If absent, zero is assumed, 
indicating that the transaction will be performed exactly once. 

The compensation element is optional. If missing, then no activities will occur when 
the transaction is compensated. 

The syntax for the transaction compensation definition is: 

<compensation> 
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Content: (documentation?, context?, {any activity }+) 

</compensation> 

3.10.1.6 Example 

In this example (taken from Section 5.4.3), the atomic transaction performs seat 
reservation. The transaction begins upon receipt of the first reservation request 
and terminates with receipt of the last reservation request. The last reservation 
request is identified by having the defs:notLastseat property set to false. In 
many cases a single reservation is made, but the transaction allows multiple 
reservations to be made as part of a single unit of work. The transaction completes 
only if all reservations were successfully completed. 

<sequence> 
<context> 

<transaction name = "seatReservation" 
type = "atomic"> 
<compensation> 

<action name = "Notif yOfCancellation" 
role.= "Airline" 

operation = "tns : AirlineToTA/Notif yOfCancellation"/> 

</transaction> 
</context> 

Oct ion name=" Re serve Seat" 
role ="Airline" 

operation="tns : AirlineToTA/ReserveSeat"/> 
<while name="ReserveSeats"> 

<condition>def s : notLastSeat</condition> 
Oct ion name="ReserveSeat" 

<correlate correlation 

</action> 



The compensating behavior for the transaction is specified as part of the 
transaction and could be invoked as part of exception handling defined in a 
following context: 

<exception> 

<onTimeout property = "tns : expiryTime" 
type = "duration" 

ref erence="tns :ReserveSeats@end"> 
<compensate transaction = "tns : seatReservation" /> 
</onTimeout> 
</exception> 

3.10.2 Compensate 



irlineToTA/ReserveSeat"> 
= "def s : reservationCorrelation" /> 
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The compensate activity is an atomic activity which performs compensation for any 
instances of the named transaction. 

<compensate 

name = NCName 

transaction = NCName> 

Content: (documentation?) 
< / c o mpensate> 

The transaction attribute specifies the transaction to compensate. The name 
must match a previously completed transaction that was performed in the current 
context. 

The activity performs compensation for any instances of the named transaction 
that occurred in the current context, have completed and have not been 
compensated for. A transaction instance is not compensated if the transaction has 
not completed successfully, or if the transaction instance has already been 
compensated for. 

3.11 Interface 

The interface element describes the WSCI view of a Web Service participating in 
a choreographed, long-lasting and stateful message exchange with other services. 
The syntax of the interface element is as follows: 

<interface 

name = NCName> 

Content: (documentation?, process+i 
</interf ace> 

The name attribute of the interface element is required and allows the interface to 
be referenced from the global model. The interface element must contain one or 
more process elements that jointly describe the details of the message exchange. 

The interface is a top-level WSCI definition. Therefore, the interface element 
appears as child of the wsdi: definitions element. 

3.11.1.1 Example 

This example shows part of the interface of the Travel Agent in the Ticket 
Reservation Process: 

<wsdl:definitions> 

<wsci : interface name = "Travelftgent" /> 
<documentation> ... </documentation> 

<process name = "PlanAndBookTrip" instantiation = "message"> 

<! --process details — > 
</process> 
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</wsci. : interf ace> 

<!--other definitions, e.g. correlations, selectors --> 
</wsdl:definitions> 

The detailed behavior of the Travel Agent in the Ticket Reservation Process is 
described inside the process pianAndBookTrip. It is not shown in the XML 
fragment above. 



4. Global model 

The WSCI Global Model allows describing a message exchange oriented view of 
the overall process in terms of interfaces representing participants in that process, 
and links between operations of communicating participants. These links indicate 
direct message flow between the linked operations. The WSCI Global Model is a 
useful tool for visual modeling, analysis, validation and simulation of the overall 
process. The syntax for the WSCI Global Model is as follows: 

<model name = NCName> 

Content : (documentation?, interface { 2, n } , connect +) 
</model> 

<interface ref = QName/> 

<connect operations = twoOpName> 

{extension attribute} 

Content: {extension element}? 
</connect> 

twoOpName = list of opName {2} 
opName = portTypeName ' / ' operationName 
portTypeName = QName 
operationName = NCName 

The model element serves as a container for the WSCI Global Model. The model 
element is a top-level definition in WSCI. The name attribute is required. The model 
element must contain at least two references to interfaces of participants, and one 
or more links between operations of communicating participants. 

The interface element references a WSCI interface. The value of the required ref 
attribute is a QName and must match the name of the referenced interface. 

The connect element describes a link between operations of communicating 
participants. Usually, those operations will be mirror images of each other. The 
operations attribute serves the purpose to connect two WSDL operations. The 
definition of the operations attribute is specifically designed to work with WSDL 
since the twoopName simple type is aligned with the naming conventions for WSDL 
port types and operations. If two operations defined in any other service 
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description language are to be connected, some extension of the connect element 
must be used. 

Example. 

The following XML fragment shows part of the global model for the Ticket 
Reservation Process. The full example is presented in Sec ti on 5 . of this 
specification. 

<wsdl : definitions name = "Traveler" 

targetNamespace = "http : //example . com/consumer/models" 
xmlns:wsdl = "http://schemas.xm.lsoap.org/wsdl/" 
xmlns = "http://www.w3.org/2002/07/wscil0" 
xmlns: tra = "http://example.com/consumer/traveler" 
xmlns: air = "http://example.com/consumer/airline" 
xmlns : ta = "http: //example . com/ consumer /travelagent"> 

<wsdl : import namespace = "http://example.com/consumer/traveler" 
location = "http://example.com/traveler.wsci" /> 

<wsdl: import namespace = "http://example.com/consumer/airline" 
location = "http://example.com/airline.wsci" /> 

<wsdl: import namespace = "http://example.com/consumer/travelagent" 
location = "http://example.com/travelagent.wsci" /> 

<model name - "AirlineTicketing"> 

<interface ref = "air : Airline" /> 
<interface ref = "tra : Traveler" /> 
<interface ref = "ta : TravelAgent" ./> 

<! — Traveler / TravelAgent — > 

<connect operations = "tra : TravelerToTA/Placeltinerary 
ta :TAtoTraveler/ReceiveTrip" /> 

<!-- other connect elements — > 

< /model > 
</wsdl : def initions> 

The Global Model presented above contains references to the interfaces of the 
three participants in the Ticket Reservation Process. The interfaces are referenced 
by their qualified names. In addition, the Global Model describes how operations 
that directly map a message flow are actually connected. In the above example, 
the Global Model describes how the piaceitinerary operation defined within the 
TraveierToTA port type and the ReceiveTrip operation defined within the 
TAtoTraveier port type are connected and, together, describe how the trip order is 
sent by the Traveler and received by the Travel Agent. For a full description of the 
Ticket Reservation Scenario please refer to Section 5. 



http://www.w3.org/TR/wsci/ 



5/8/2007 



Web Service Choreography Interface (WSCI) 1.0 



Page 71 of 128 



5. Example 

5.1 Overview 

This section provides a comprehensive example that illustrates how WSCI can be 
used to model a scenario that better reflects the real life business process of 
reserving and booking airline tickets. 

This example expands on the simple one introduced in Section 1.7, so that it will 
highlight the use of each construct of the WSCI syntax (as described in Section 3). 

The scenario now includes three participants: a Traveler, a Travel Agent, and an 
Airline Reservation System. This section will guide through the definition of the 
WSCI interfaces of each participant as they collaborate in the overall process 
called pianAndBookTrip. The actual implementation of these interfaces is up to 
each party to decide; WSCI is completely agnostic on this. Perhaps the Traveler is 
using a browser-based plug-in web service, like a specialized applet or a mail 
agent. Perhaps the travel agent has it own tailored web service. Perhaps the 
airline has a web service that comes built into its overall reservation application. 

In the following, picture, the dotted circle highlights the scope of this example, 
namely the definition of a WSCI interface for each participant, and the global 
model describing how those interfaces interact. 




Figure 5-1 



5.2 Use Case definition 
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The high level flow of the messages exchanged within the "Plan And Book Trip" 
process can be visualized as per the following picture: 



Traveler °^ e ll r,p . , J "*"" Travel Agent 




Figure 5-2 



The following description of the scenario makes use of the step labels shown in 
the picture. 

A Traveler is planning on taking a trip. She decides where to go (her final 
destination) and when to leave and return. These activities are performed 
independently on any specific contact the Traveler may have with the Travel Agent 
(for instance, the trip may be planned using a catalogue or any other means which 
do not involve connecting to the Travel Agent site). 

Once she picks her preferred plan, she submits her choice to a Travel Agent by 
means of her local Web Service software (Order Trip). 

The Travel Agent evaluates which is the best itinerary to reach the desired 
destination, based on the Traveler's criteria such as cheapest price, availability of 
destination, type of plane or frequent flyer miles. The Travel Agent finds that the 
best travel plan includes one or more discrete journeys, or legs which, for the sake 
of simplicity, will all be operated by the same Airline. 

For each leg, the Travel Agent asks the Airline Reservation System to verify the 
availability of seats (Verify Seats Availability). This availability is constrained by the 
departing/arrival time information and by the Traveler's seat choice. For each leg, 
the Airline Reservation System provides information about the availability of a 
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particular seat. Note that the Travel Agent may have to restart the whole selection 
in case the Airline would not be able to verify the availability of a given seat. 

Once the ideal travel plan has been validated, the Travel Agent builds a proposed 
itinerary for the Traveler to verify. This itinerary might actually not be satisfactory to 
the Traveler for various reasons. So, the Traveler has the choice of accepting or 
rejecting the proposed itinerary as well as she may decide not to take the trip at 
all. 

• In case she rejects the proposed itinerary, she may submit the modifications 
(Change Itinerary) and wait for a new proposal from the Travel Agent. 

• In case she decides not to take the trip, she informs the Travel Agent about 
her decision (Cancel Itinerary) and the process ends. 

• In case she decides to accept the proposed itinerary (Reserve Tickets), she 
will provide the Travel Agent with her Credit Card information in order to 
properly book the itinerary. The Traveler will, also, provide her contact 
information for the Airline Reservation System since the Traveler wants to 
receive an e-Ticket directly from the Airline. 

Next, the Travel Agent connects with the Airline Reservation System in order to 
finalize the seat reservation (Reserve Seats). The Airline Reservation System 
electronically reserves the seats associated to each leg; the validity period for 
such reservation is of one day meaning that if a final confirmation will not be 
received within one day, tickets will be unreserved and the Travel Agent will be 
notified. 

Next, the Travel Agent informs the Traveler about the reservation of the seats. 

The Traveler can now either finalize the reservation or cancel it. If she confirms the 
reservation (Book Tickets), the Travel Agent asks the Airline Reservation System 
to finally book the seats (Book Seats). The Airline Reservation System books the 
seats for the chosen itinerary and, then, issues an e-ticket to the Traveler (Send 
Tickets). 

Finally, the Travel Agent charges the Traveler's Credit Card with the relevant 
amount and sends the notification of the charge (Send Statement) together with a 
detailed description of the itinerary to the Traveler. 

5.3 Building from the simple example 

The three participants will define their respective WSCI interfaces for this process 
(see Section 5.4). To properly interact, the interfaces should form 'mirror images' 
of each other, so that the WSCI action of one is 'matched' with a corresponding 
WSCI action of another. In this example, thus, the overall picture looks like the 
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following figure. 
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Figure 5-3 



This picture shows: 

• All the WSCI actions in each interface 

• The choreography of actions within each interface, as described by each 
participant's WSCI interface 



• The message flow from action to action 

In the remaining part of this section, the details required to understand each 
participant's WSCI interface will be explained; the intent of the explanations has 
always been to describe how the WSCI modeling constructs have been used to 
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extend the simple scenario. Special attention has been given to present as many 
WSCI constructs as possible; therefore, different modeling techniques and 
constructs could have been used to describe the same 3 interfaces. 

Note that the main top-level processes of each the participant interfaces are 
consistently named in the same way {PlanAndBookTrip). This is not enforced 
anywhere by WSCI; this convention has been chosen to explicitly show that all the 
interfaces refer to the same logical process (the Ticket Reservation process). In 
fact, each Web service may participate in more than one logical process and 
would expose a different interface for each one. 

5.4 WSCI Interfaces 

5.4.1 The Travel Agent Interface 

5.4.1.1 Modeling details 

• Once the Travel Agent receives an initial order from the Traveler 
(Receiveiriporder action), he needs to verify with the Airline Reservation 
System if seats are available for the desired trip. The verification is 
implemented via a nested process invoked within the ReceiveTripOrder 
action. This allows keeping the solicit-response semantic that is expected by 
the Traveler (the interaction of the Traveler should not be influenced by the 
way in which the Travel Agent actually communicates with other participants) 
and the corresponding request-response semantic for the Travel Agent. 

The verifyseats nested process is described by means of a while activity 
whose condition is represented by the openings property; this property is 
evaluated against the internal implementation of the Travel Agent service. 

Note that the nested process is declared inside the context for the sequence 
activity. 

• In order to model the possibility for the Traveler to change the initial itinerary, 

a nested processes (Changeltinerary) With instantiation=message is 

declared in the context (note that a nested process with 

instantiation=message can occur at any time and any number of times 
inside the execution context). 

The changeltinerary nested process calls the verifyseat nested process 
(this is a concrete example of how the process element allows reusability). 

• If the Traveler decides to dismiss the trip request, an exception declared in 
the context captures the withdrawal. When the exception is caught, the 
context in which such exception is managed gets terminated; to terminate 

the PlanAndBookTrip process, the fault activity is used; without the use of 
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the fault, the execution would have resumed just after the activity set 
associated with the context declaring the exception handler. 

• Note that the previous exception, as well as the changeitinerary nested 
process, are only available once the containing context is active; this 
ensures that the interface correctly describes that the Travel Agent needs to 
perform the ReceiveTripOrder action before being able to execute the 
nested process and/or process the exception. 

• If the Traveler decides to confirm the itinerary, the ReceiveReservation 
action is executed. This action references the itinerarycorreiation; this 
correlation is, implicitly, instantiated by the previous action 
(Receiveiriporder) which actually provides the correlation identifier 
(itinerarylD) to the Traveler. This identifier is the one that is used by the 
itinerarycorreiation and which makes sure that the proper context is 
retrieved. 

• The Reserveseats nested process is called from within the 
ReceiveReservation action and iterates though the selected legs using the 
foreach activity; at each iteration, a reservation of the related seat with the 
Airline Reservation System is performed (Reserveseat). 

The foreach statement has been used (instead, for instance, of a while 
statement) since the number of iterations does not depend on any condition 
but only on the number of legs. 

• The ReserveFirstseat action outside of the foreach statement properly 
instantiates the reservationcorreiation correlation; this correlation, then, 
enables the Travel Agent to properly correlate subsequent messages from 
the Traveler (e.g. when booking the tickets) or the Airline Reservation 
System (e.g. when the reservation times out) to the conversation. 

Note that, Within the ReceiveReservation action, the itinerarycorreiation 

is referenced; the reservationcorreiation is instantiated by means of the 
ReserveFirstseat action in the called nested process. 

• Once the reservation has been done, the Traveler could finally confirm the 
trip or change her mind and cancel the reservation. It could also happen that 
the reservation was hold for too long by the Airline Reservation System and, 
thus, it could be no more valid. 

To express these semantics, the behavior of the Travel Agent has been 
modeled via the use of an Exception Handler. 

o In case a timeout notification from the Airline Reservation System is 
received, a notification is sent to the Traveler and a fault activity 
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ensures that the process is terminated. 



o In case the Traveler changes her mind and dismisses her reservation, 
the Travel Agent notifies the Airline Reservation System (in an 
asynchronous way, note the use of two separate actions involving the 
Travel Agent and the Airline Reservation System) and the Traveler is 
positively notified of the acceptance of her withdrawal. The execution of 
the fault activity ensures that the process is terminated. 

• Once the Traveler confirms the reservation and such reservation is properly 
taken care by the Airline Reservation System (via the execution of the 
Bookseats nested process within the Receiveconfirmation action), the 
Travel Agent bills the Traveler only in case the Credit Card details are 
accurate. This has been modeled by means of an until activity iterating over 
the paymentoK condition; the Travel Agents loops until he gets a confirmation 
containing accurate Credit Card details. 

PaymentoK is a condition internally managed by the Web service 
implementation; its value is true whenever the Credit Card of the Traveler is 
correctly debited. 

• The interface exhibited by the Travel Agent uses two different correlations: 

itineraryCorrelation and reservationCorrelation. Collectively, the tWO 

correlations identify the same conversation involving the Travel Agent with 
both the Traveler and the Airline Reservation System. 



5.4.1.2 The WSCI interface 



<?xml version = "1.0" ?> 

<wsdl : definitions name = "TravelAgent" 

targetNamespace = "http : //example . com/consumer/travelagent" 
xmlns = "http:// www .w3.org/2002/07/wscil0" 
xmlns:wsdl = "http://schemas.xmlsoap.org/wsdl/" 
xmlns : tns = "http : //example . com/consumer/travelagent" 
xmlns : def s = "http : //example . com/ consumer/definitions'^ 

<wsdl : import namespace = "http://example.com/consumer/definitions" 
location = "http://example.com/messages.wsdl" /> 

<wsdl: import namespace = "http://example.com/consumer/definitions" 
location = "http://example.com/definitions.wsci" /> 



* TRAVEL AGENT INTERFAX: 



<interface name - "TravelAgent"> 
<documentation> 

The interface models the behavior of the travel agent service with 
respect to all of the other parties involved in the overall process. 
</documentation> 
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<process name = "PlanAndBookTrip" instantiation = "message"> 
<sequence> 
<context> 

<process name = "Verif ySeats" instantiation = "other"> 
<while> 

<condition>tns :openLegs</condition> 
<action name = "CheckSeatAvailability" 
roie = "tns : travelAgent" 

operation = "tns : TAtoAirline/CheckSeatAvailability"> 
</action> 
</while> 
</process> 

<process name = "ReserveSeats " instantiation = "other"> 
<action name = "ReserveFirstSeat" 
role = "tns : travelAgent" 

operation = "tns : TAtoAirline/ReserveSeat" > 
<correlate correlation = "def s : reservationCorrelation" 
instantiation = "true" /> 

</action> 

<foreach select="//proposedItinerary/leg [position () >1 ] "> 
<action name = "ReserveSeat" 

role = "tns : travelAgent" 

operation = "tns : TAtoAirline/ReserveSeat" /> 

</ f oreach> 
</process> 

<process name = "Changeltinerary" 

instantiation = "message"> 
<action name = "Changeltinerary" 
role = "tns : travelAgent" 

operation = "tns : TAtoTraveler/ChangeItinerary"> 
<correlate correlation="def s : itineraryCorrelation" /> 
<call process = "Verif ySeats"/> 

</ P rocess> 

<exception> 
<onMessage> 

<action name = "Cancel It inerary" 
role = "tns : travelAgent" 

operation = "tns : TAtoTraveler/CancelItinerary"> 
<cor relate correlation="def s : itineraryCorrelation" /> 
</action> 

<fault code = "tns : itineraryCancelled" /> 
</onMessage> 
</exception> 

</context> 

<action name = "ReceiveTripOrder " 
role = "tns : travelAgent" 

operation = "tns : TAtoTraveler/OrderTrip"> 
<call process = "Verif ySeats " /> 
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Oction name = "ReceiveReservation" 
role = "tns : travelAgent" 

operation = "tns : TAtoTraveler/ReserveTickets"> 
<correlate correlation = "def s : itineraryCorrelation" /> 
<call process = "ReserveSeats"/> 

</sequence> 

<until> 

<condition>tns : paymentOK</condition> 
<documentation> 

We catch the non-standard behavior meaning the reception of 
timeout and cancellation. If this is an exception, the 
repeat-until is terminated and the sequence resumes outside 
the repeat-until 
</documentation> 

<context> 

<process name = "BookSeats" instantiation = "other"> 
Oction name = "bookSeats" 

role = "tns : travelAgent" 

operation = "tns : TAtoAirline/bookSeats"> 

</action> 
</process> 

<exception> 
<onMessage> 

Oction name = "ReservationTimedOut" 
role = "tns : travelAgent" 

operation = "tns : TAtoAirline/AcceptCancellation"> 
<correlate 

correlation = "def s : reservationCorrelation"/> 

Oction name = "NotifyOf Timeout" 
role = "tns -.travelAgent" 

operation = "tns : TAtoTraveler /NotifyOf Cancellation" /> 

<fault code = "tns : reservationTimedOut"/> 

</onMessage> 

<onMessage> 

Oction name = "ReceiveCancellationRequest" 
role = "tns: travelAgent" 

operation = "tns : TAtoTraveler/CancelReservation "> 
<cor relate correlation "def s : reservationCorrelation"/> 
</action> 

Oction name = "CancelReservation" 
role = "tns : travelAgent" 

operation = "tns : TAtoAir 1 i r = - ^ -z iation"/> 

<action name = "ReceiveCancellationNotif ication" 
role = "tns : travelAgent" 

operation = "tns : TAtoAirline/AcceptCancellation"> 
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<correlate 

correlation = "def s : reservationCorrelation" /> 

<action name = "NotifyOf Cancellation" 
role = "tns: travelAgent" 

operation="tns:TAtoTraveler/NotifyOf Cancellation" /> 



<fault code = "tns : reservationCancelled"/> 
</onMessage> 
</exception> 
</context> 



<action name = "ReceiveConf irmation" 
role = "tns : travelAgent " 

operation = "tns : TAtoTraveler/bookTickets"> 
^-correlate correlation="def s : reservationCorrelation" /> 
<call process = "BookSeats" /> 
</action> 
</until> 

<action name = "SendStatement" 
role = "tns : travelAgent" 

operation = "tns : TAtoTraveler /SendStatement" /> 



</process> 
</interf ace> 



* TRAVEL AGENT PORT TYPES 



<wsdl : port Type name = " TAtoTraveler " > 

<w : >n> 

This port type contains operations which the Travel Agent 
service uses to connect with the Traveler service 

</wsdl : documentation> 



<wsdl : operation name = "OrderTrip"> 

<wsdl: input message » "defs:trip - juest"/> 

<wsdl : output message = "def s : tripOrderAcknowledgement"/> 

</wsdl :operation> 

<wsdl : operation name = "Changeltinerary"> 

<wsdl : input message = "def s : changeItineraryRequest"/> 
<wsdl : output message = "def s : changeltineraryConf irmation"/> 

</wsdl : operation> 



< 3 : jperation name = "Cancelltinerary"> 

<wsdl : input message = "def s : cancelltineraryReques - 
<wsdl : output message = "def s : cancelltineraryConf i: 

</wsdl : operation> 



<wsdl : operation name = "ReserveTickets"> 

<wsdl: input message = "def s : reservationRequest"/> 
<wsdl: output message = "def s : reservationConf irmation" /> 
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</wsdl : operation> 

<wscii : operation name="CancelReservation"> 

<wsdl : input message="def s : reservationCancellationRequest"/> 
</wsdl : operation> 

<wsdl : operation name = "Motif yOf Cancellation'^ 

<wsdl : output message = "def s : reservationCancellationResponse" /> 
</ wsdl : operation> 

<wsdl : operation name = "bookTickets"> 

<wsdl : input message = "def s :bookingRequest"/> 
<wsdl : output message = "def s rbookingConf irmaticn"/> 

</wsdl : operation> 

<wsdl : operation name = "SendStatement"> 

<wsdl : output message = "def s : statement "/> 
</wsdl : operation> 
</wsdl :portType> 

<wsdl :portType name = "TAtoAirline"> 

<wsdl : documentation> 

This port type contains operations which the Travel Agent 
service uses to connect with the Airline service 

</wsdl : documentation> 

<wsdl : operation name = "CheckSeatAvailability"> 

<wsdl: output message = "def s : seatAvailabilityCheck"/> 
<wsdl: input message = "def s : seatAvailability"/> 

</wsdl : operation> 

<wsdl : operation name = "ReserveSeat"> 

s- _ : - - t t - " ~ : - ' - • • - " / > 

<wsdl : input message = "def s : seatReservationConf irmation" /> 
</wsdl :operation> 

<wsdl : operation name = "RequestCancellation"> 

<wsdl: output message = "def s : reservationCancellationRequest"/> 
</wsdl : operation> 

<wsdl : operation name = "AcceptCancellation"> 

<wsdl: input message = "def s : reservationCancellationResponse"/> 
</wsdl:operation> 

<wsdl : operation name = "bookSeats"> 

<wsdl: output message = "def s : ticketOrderRequest"/> 
<wsdl: input message = "def s : ticketOrderConf irmation" /> 
</wsdl : operation> 
</wsdl :portType> 
</wsdl:definitions> 

5.4.2 The Traveler Interface 
5.4.2.1 Modeling details 
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The Traveler interface has not been modeled in the simple example. 

• The main, top-level process describing the behavior of the Traveler, is 
declared with the instantiation=other attribute. This describes the fact that 
the Traveler is actually the one who starts the message exchange 
associated with the logical process and that the start does not correspond to 
the receipt of any message described by the logical process. 

• After ordering the trip (orderTrip action), the Traveler can reserve the tickets 
for such trip (ReserveTickets). She could, also, change the chosen itinerary 
(changeitinerary) or withdraw her request (canceiitinerary) at any time; 
this may be because the Travel Agent was not able to properly select the 
desired itinerary or, simply, because the Traveler changed her mind. 

The activity of changing the itinerary is modeled by using a nested process 

(Changeitinerary) defined With the instantiation=other attribute to Signify 

that it is not automatically triggered by the reception of a specific message. A 
nested process can be started any time and any number of times within the 
context in which it is defined. 

The activity of withdrawing the request has been modeled in a switch 
statement since it can only be performed once; the fault statement explicitly 
terminates the process. 

Also note that the switch activity is enclosed in a sequence in order to 
constrain the usage of the nested process to the specific context in which the 
switch is performed. 

• The Traveler can, then, book the tickets (sookTickets) or withdraw the 
reservation (canceiReservation) or be notified that the Airline Reservation 
System actually held the initial reservation for too long a period. 

The modeling of such situation is done by means of a new context defined 
in a new sequence activity; this new context defines an exception handler that 
manages the reception of the timeout notification from the Travel Agent Web 
service. The exception handler, once activated, terminates the execution of 
the top-level process because of the explicit use of the fault activity. 

• The BookTickets action instantiates the bookingcorreiation which is, later, 
used by the Airline Reservation System and by the Travel Agent to ensure 
that the tickets and the statement are properly received by the Traveler. 

The correlation contains the bookingio property that is conveyed by the 
response from the Travel Agent. The Travel Agent himself receives the 
bookingir, from the Airline; this ensures that both the Travel Agent and the 
Airline Reservation System know how to fulfill the correlation requirements 
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exhibited by the Traveler interface. 

• Finally, the Traveler will receive the statement from the Travel Agent 
(Receivestatement) as well as the tickets from the Airline Reservation 
System (p.eceiveTickets). Since these two actions do not need to be 
performed in any specific order, the an activity has been used. 

Note that the bookingcorreiation is used in both cases. 



5.4.2.2 The WSCI interface 



<?xml version = "1.0" ?> 

<wsdl : definitions name = "Traveler" 

targetNamespace = "http: //example . com/consumer /traveler " 
xmlns = "http://www.w3.org/2002/07/wscil0" 
xmlns :wsdl = "http://schemas.xmlsoap.org/wsdi/" 
xmlns:tns = "http://example.com/consumer/traveler" 
xmlns : def s = "http : //example . com/ consumer /definitions " 

<wsdl : import namespace = "http://example.com/consumer/def 
location = "http://example.com/messages.wsdl" / 

<wsdl : import namespace = "http://example.com/consumer/def 
location = "http://example.com/definitions.wsci 



* TRAVELER INTERFACE ' 



<interface name = "Traveler"> 
<documentation> 

The interface models the behavior of the Traveler service with 
respect to all of the other parties involved in the overall process. 
< / do c ume n t a t i o n > 



<prccess name = "PlanAndBookTrip" instantiation = " other "> 

<action name = "OrderTrip" 
role = "tns : traveler" 

operation = "tns : TravelerToTA/OrderTrip" /> 

<sequence> 
<context> 

<process name = "Changeltinerary" instantiation = "other"> 
<documentation> 

Allows the traveler to change the itinerary as often as 
she likes. 
</documentation> 

•Caction name = "Changeltinerary" 
role = "tns: traveler" 

operation = "tns : TravelerToTA/Changeltinerary" /> 

</process> 
</context> 
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<switch> 
<case> 

<condition>tns : cancelItinerary</condition> 
<action name = "Cancelltinerary" 
role = "tns : traveler" 

operation = "tns : TravelerToTA/Cancelltinerary" /> 
<fault code = "tns: exit" /> 

<default> 

<action name = "ReserveTickets" 
role = "tns : traveler" 

operation = "tns : TravelerToTA/ReserveTickets"> 
<correlate correlation="def s : reservationCorrelation" 
instantiation= "true" /> 

</action> 
</default> 
</switch> 
</sequence> 

<sequence> 

<documentation> 

The context of this sequence traps the timeout for the 
reservation. The Timeout would abort the whole process. 
Also, it allows the traveler to cancel the trip. 
< / documen tat i on> 
<context> 
<exception> 
<onMessage> 

<action name = "ReservationTimedOut " 
role = "tns : traveler " 

operation = "tns : TravelerToTA/AcceptCancellation"> 
<correlate correlation="def s : reservationCorrelation" /> 
</action> 

<fault code = "tns:exit"/> 

</onMessage> 
</exception> 
</context> 

<switch> 
<case> 

<condition>tns : cancelReservation</condition> 
Oct ion name = "CancelReservation" 
role = "tns : traveler " 

operation = " tns : TravelerToTA/RequestCancellation" /> 
<action name = "AcceptCancellation" 
role = "tns : traveler" 

operation = "tns : TravelerToTA/AcceptCancellation"> 
<correlate 

correlation = "defs : reservationCorrelation" /> 

<fault code = "tns : exit" /> 
</case> 
<default> 

<action name = "BookTickets" 
role = "tns : traveler" 

operation = "tns : TravelerToTA/BookTickets"> 
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<correlate correlation = "def s rbookingCorrelation" 
instantiation = "true"/> 

</action> 
</default> 
</switch> 

<all> 

<action name = "ReceiveTickets" 
role = "tns: traveler" 

operation = "tns : TravelerToAirline/ReceiveTickets"> 
<correlate correlation = "def s rbookingCorrelation" /> 
</action> 



n name = "ReceiveStatement" 
role = "tns : traveler" 

operation = "tns : TravelerToTA/ReceiveStatemen 
relate correlation = "def s : bookingCorrelation" 



r TYPES 



<wsdl : portType name = "TravelerToTA"> 
<wsdl : documentation> 

This port type contains operations which the Traveler service 

uses to connect with the Travel Agent service 
</wsdl :documentation> 

<wsdl : operation name = "OrderTrip"> 

<wsdl: output message = "def s : tripOrderRequest"/> 
<wsdl: input message = "defsrtr: - ledgement"/> 

</wsdl : operation> 

<wsdl : operation name = "Changeltinerary"> 

<wsdl : output message = "def s : changeItineraryRequest"/> 
<wsdl : input message = "def s : changel'tineraryConf irmation"/> 

</wsdl : operation> 

<wsdl : operation name = "Cancelltinerary"> 

<wsdl:output message = "def s : cancel I t.i ner ar yRequest " /> 
<wsdl : input message = "def s : canceiltineraryConf irmation"/> 

</wsdl : operation> 

<wsdl: operation name = "ReserveTickets"> 

<wsdl : output message = "defs : reservationRequest"/> 
<wsdl: input message = "def s : reservationConf irmation" /> 

</wsdl : operation> 

<wsdl : operation name = "RequestCancellation"> 

<wsdl: output message = "def s : ReservationCancellationRequest"/> 
</wscil : operation:;- 
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<wsdl : operation name = "AcceptCancellation"> 

<wsdl : input message = "def s :ReservationCancellationResponse"/> 
</wsdl : operation> 

<wsdl : operation name = "BookTickets"> 

<wsdl: output message = "defs:bookingRequest"/> 
<wsdl : input message = "defs :bookingConf irmation"/> 

</wsdl : operation> 

<wsdl : operation name = "ReceiveStatement"> 

<wsdl: input message = "def s : statement"/> 
</wsdl : opera tion> 
</wsdl :portType> 

<wsdl :portType name = "TravelerToAirline"> 
<wsdl : documentation> 

This port type contains operations which the Traveler service 

uses to connect with the Airline service 
</wsdl : documentation> 

<wsdl : operation name = "ReceiveTickets"> 

<wsdl : input message = "defs : tickets"/> 
</wsdl : operation> 
</wsdl :port?ype> 
</wsdl:definitions> 

5.4.3 The Airline Interface 
5.4.3.1 Modeling details 

The Airline Reservation System interface has not been modeled in the simple 
example. It exhibits two different top level processes, both with the 

instantiation-message attribute: 

• verifyseats models the activities that are performed when the Travel Agent 
requests the verification that the planned itinerary is actually possible. 

• pianAndBookTrip models the activities that are performed to actually reserve 
the seats, to finalize the reservation and to deliver the tickets. 

In detail, the PianAndBookTrip process uses the following modeling techniques: 

• Each seat is actually reserved separately (corresponding to the foreach 
activity in the Travel Agent interface). 

The Reserveseat action outside of the while loop is the first action within the 
PianAndBookTrip process; the reservationiD for the trip reservation is 
created at this point by the Airline and is communicated to the Travel Agent; 
this means that the Airline is instantiating the reservationcorreiation for 
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itself. 

The Travel Agent uses the reservation^ in order for the Airline Reservation 
System to properly relate the incoming messages to the execution context. 

Note that both the Travel Agent and the Airline have instantiated the 

reservationCorrelation in their OWn process. 

• The condition driving the while activity is modeled by means of an 
expression which evaluates to false when the last leg within the trip is 
received. 

• The actions previously described are included in a sequence activity which 
establishes a context defining an atomic transaction (seatReservation). 

This transaction informs the client of the Airline Reservation System (the 
Travel Agent Web service, in this case) that the multiple seat reservations 
are actually performed in a transactional way by the service; since the 
transaction is atomic, this means that either all seat reservations will be 
performed or the Airline Reservation System will automatically roll them 
back. 

The transaction also defines a compensation activity which, once executed, 
probably will withdraw the reservations for all the seats (details of this 
behavior are of no interest from an interface point of view) and will notify the 
Travel Agent about the withdrawal (Notifyofcanceiiation action). This 
notification is the only observable behavior exhibited by the compensation 
activity itself. 

• The behavior of the Airline Reservation System at this point is described by 
means of the choice activity. The choice describes how the Web service can: 

o Receive a withdrawal notification from the Travel Agent, in which case 
it will simply compensate the seatReservation transaction (the 
compensation notifies the Travel Agent Web service about the positive 
execution of the withdrawal). 

o Receive the order of performing the final booking (PerformBooking), in 
which case it will send the tickets to the Traveler (actually, the tickets 
will be physically delivered at the Airline counter at the departure 
airport; electronically, a message is sent to the Traveler interface to 
confirm the physical action). 

• Note that the choice activity previously described is, itself, contained in a 
sequence activity. The reason for this is that the sequence activity defines a 
context where the "timeout" exception is handled. 
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The timeout exception handler asserts the following: 



o The timeout is actually calculated starting from the moment in which 
the ReserveSeat action terminates (a timer probably is started after the 
first seat has been reserved). The duration of the timeout is described 
by means of the property tnsrexpiryTime. 

o The timeout exception is handled by executing the compensation 
activity for the ReserveSeat transaction (which, as usual, notifies the 
Travel Agent Web service about the positive execution of the 
withdrawal) 



5.4.3.2 The WSCI interface 



xml version = "1.0" ?> 

■sdl: definitions name = "Airline" 
targetNamespace = "http: //example . com/consumer/airline" 
xmlns = "http://www.w3.org/2002/07/wscil0" 
xmlns : def s = "http : //example . com/ consumer/definitions" 
xmlns :tns = "http://example.com/consumer/airline" 
xmlns :wsdl = "http://schemas.xmlsoap.org/wsdl/" > 

<wsdl : import namespace = "http://example.com/consumer/definitio 
location « "http://example.com/messages.wsdl" /> 

<wsdl: import namespace = "http://example.com/consumer/definitio 
location = "http://example.com/definitions.wsci" /> 



-'A IRIAN A INTER I AC R 



<interface name="Airline"> 
<documentation> 

The interface models the behavior of the Airline service with 
Respect to all of the other parties involved in the overall 

< / documentati o n > 

<process name="Verif ySeats" instantiation** "message"> 
Oct ion name="Verif ySeat Availability" 
role="tns : Airline" 

operation-" tns : Air lineToTA/Ver if ySeat.Avai lability "> 
</action> 
</process> 

<process name="PlanAndBookTrip" instantiation- "message" > 
<sequence> 
<context> 



<compensation> 

<action name = "Notif yOf Cancella 
role = "tns : Airline" 
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operation = "tns: Airline mcellation"/> 
</compensation> 

</transaction> 
</context> 

<action name="ReserveSeat" 
role ="tns : Airline" 

operations" tns :AirlineToTA/ReserveSeat"/> 

<while name="ReserveSeats"> 

<condition>def s : not Last Seat</condition> 
<action name="ReserveNextSeat " 
role ="tns : Airline" 

operation="tns : AirlineToTA /Reserves eat "> 
<correlate correlation = "def s : reservationCorrelation" 
</action> 
</while> 
</sequence> 

sequence > 
<context> 

<excepti.on> 

<onTimeout property = "tns : expiryTime" 
type = "duration" 

ref erence="tns : ReserveSeats@end"> 
<compensate name = "CompensateReservation" 

transaction = " seatReservation" / > 

</onTimeout> 
</exception> 
</context> 

<choice> 

<onMessage> 

<action name - "ReceiveCanceiiationRequest" 
role ="tns : Airline" 

operation="tns : Airline! : - » CancelReservation"> 
< correlate correlation="def s : reservatior,Correlation"/> 
</action> 

<compensate name = "CompensateReservation" 
transaction = "seatReservation"/> 

</onMessage> 



<action name="Ferf ormBooking" 
role ="tns: Airline" 

operation="tns:AirlineToTA/BookSeats"> 
<cor relate cor rel ation= " de f s : reservationCorrelation" /> 
</action> 

<action name="SendTickets" 
role ="tns : Airline" 

operation="tns : AirlineToTraveler/SendTickets"/> 
</onMessage> 
</choice> 
</sequence> 
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</process> 
interf a.ce> 



*AIRLINE PORT TYPES 



<wsdl :portType name="AirlineToTA"> 

<wsdl : operation name="Verif ySeatAvailability"> 

<wsdl : input message="def s : seatAvailabilityCheck"/> 
<wsdl : output message="def s : seatAvailability" /> 

</wsdl : operation> 



<wsdl : operation narrie="ReserveSeat"> 

<wsdl : input message="def s : seatReservationRequest"/> 
<wsdl : output message="def s : seatReservationConf irmation"/> 

</wsdl : operation> 

<wsdl : operation name="Cance - - ation"> 

<wsdl : input message="def s :reservationCancellationRequest"/> 
</wsdl : operation> 

<wsdl : operation name = "Notif yOf Cancellation"> 

<wsdl : output message = "def s : reservationCancellationResponse" /> 
< / ws d 1 : opera t i on > 

<wsdl : operation name="BookSeats"> 

<wsdl : input message="def s : ticketOrderRequest"/> 
<wsdl : output message="def s : ticketOrderConf irmation" /> 

</wsdl : operation> 
</wsdl : port Type > 



<wsdl :port.Type name="AirlineToTraveler "> 
<wsdl : operation name="SendTickets"> 

<wsdl :output message="def s : tickets"/> 

</wsdl : operation> 
</' wsdl : portType> 
</wsdi:definitions> 



5.5 Correlations and Selectors definitions 



?xml version = "1.0" ?> 

wsdl :def initions name = "WSCI_Def initions" 

targetNamespace = "http: //example . com/ consumer /'def initions" 
xmlns:tns = "http://example.com/consumer/definitions" 
xmlns : wsdl = "http : //schemas . xmlsoap . org /wsdl/" 
xmlns = "http://www.w3.org/2002/07/wscil0"> 

<wsdl: import namespace = "http://exampIe.com/consvuner/defi 
location = "http://example.com/messages.wsdl" /> 



SELECTORS 
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<selector property = "tns : itineraryNo" 
type = "tns : itinerarylD" 
xpath = "./textO" /> 

<selector property = "tns : itineraryNo" 
type = "tns : itinerary" 
xpath = "./itinerarylD/textO" /> 

<selector property = "tns : itineraryNo" 
type = "tns : proposedltinerary" 
xpath = "./itinerarylD/text () " /> 

<selector property = "tns : reservationNo" 
type = "tns : reservationID" 
xpath = " . /text () " /> 

<selector property = "tns : bookingNo" 
type = "tns :bookingID" 
xpath = " . /text () " /> 

<selector property = "tns : notLastSeat" 
type = "tns : seatToReserve" 
xpath = "./notLast" /> 



CORRELATIONS 



<correlation name = "itineraryCorrelation" 
property = "tns : itineraryNo"> 
<documentation> 

Correlation based on an itinerary number 
</ document a tion> 
</correlation> 



<correlation name = "reservationCorrelatic 
property = "tns : reservationNo" 
<documentation> 

Correlation based on a reservation numbe 
</documentation> 
</correlation> 



correlation name = "bookingCorrelation" 
property = "tns : bookingNo"> 
<documentation> 

Correlation based on a booking number. 
</documentation> 
</correlation> 
< ; s d 1 : de f i n i t i o n s > 

5.6 Global Model 
5.6.1 Modeling details 
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Here is a graphical representation of the WSCI Global Model. 
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Figure 5-4 



5.6.2 The WSCI global model 

<?xml version = "1.0" ?> 

<wsdl : definitions name = "GlobalModel " 

targetNamespace = "http : //example . com/ consumer /models" 
xmins « "http://www.w3.org/2002/07/wscil0" 
xmlns:wsdl = "http://schemas.xmlsoap.org/wsdl/" 
xmlns :tra = "http://example.com/ccnsumer/traveler" 
xmlns : air = "http : //example . com/consumer/airline" 
xmlns : ta = "http: //example . com/consumer/travelagent"> 

<wsdl: import namespace = "http://example.com/consumer/traveler" 
location = "http://example.com/traveler.wsci" /> 

<wsdl: import namespace = "http://example.com/consumer/airlxne" 
location = "http://example.com/airline.wsci" /> 
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<wsdl: import namespace = "http://example.com/consumer/travelagent" 
location = "http://exainple.com/travelagent.wsci" /> 

<model name = "AirlineTicketing"> 

<interface ref = "air rAirline" /> 
<interface ref = "tra : Traveler" /> 
<interface ref = ."ta : TravelAgent" /> 

<! — Traveler / TravelAgent — > 

<connect operations = "tra : TravelerToTA/Placeltinerary 
ta :TAtoTraveler/ReceiveTrip" /> 

<connect operations = "tra : TravelerToTA/Changeltinerary 
ta:TAtoTraveler/ChangeItinerary" /> 

<connect operations = "tra : TravelerToTA/Deleteltinerary 
ta:TAtoTraveler/DeleteItinerary" /> 

<connect operations = "tra : TravelerToTA/Perf ormReservation 
ta :TAtoTraveler/ReceiveReservation" /> 

<connect operations = "tra :.TravelerToTA/RequestCancellation 
ta:TAtoTraveler/CancelReservation" /> 

<connect operations = "tra : TravelerToTA/AcceptCancellation 
ta : TAtoTraveler/Notif yOfCancellation" /> 

<connect operations = "tra : TravelerToTA/FinalizeReservation 
ta : TAtoTraveler/AcceptConf irmation" /> 

<connect operations = "tra : TravelerToTA ReceiveStatement 
ta:TAtoTraveler/SendStatement" /> 

<!-- Traveler / Airline — > 

<connect operations = "tra : TravelerToAirline/ReceiveTickets 
air : AirlineToT ravel er / SendTi ckets " /> 

<! — Travel Agent / Airline — > 

<connect operations = "ta : TAtoAirline/CheckAva ilabi lity 

air :AirlineToTA/VerifySeat Availability" /> 

<connect operations = "ta : TAtoAirline/ReserveSeats 
air :AirlineToTA/ReserveSeats"/> 

<connect operations = "ta:TAtoAirline/RequestCancellation 
air :AirlineToTA/CancelReservation" /> 

< c o n n e c t operations = " t a : T A t o A i r 1 i n e / A c cept C a n c e 1 1 a t i o n 

air :AirlineToTA/Not if yOfCancellation" /> 

<connect operations = "ta : TAtoAirline/Conf irmBooking 
air :AirlineToTA/Eooking"/> 
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</wsdl :def initions> 

5.7 WSDL Types and Messages 

This file describes the WSDL abstract messages that the participants in the Airline 
Ticketing Example exchange among themselves, and the types required to define 
these messages. 

<?xml version = "1.0" ?> 

<def initions name = "TypesAndMessages" 

targetName space = "http : //example . com /consumer /definitions" 
xmlns : xsd = "http : / /www . w3 . org/20 0 0/10 /XMLSchema " 
xmlns : xsdl = "http : //example . com/consumer/definitions" 
xmlns = "http://schemas.xmlsoap.org/wsdl/"> 

<types> 

<schema xmlns = "http://www.w3.org/2000/10/XMLSchema"> 
<;__ ****************** SIMPLE TYPES *************************** __> 



<simpleType name = "itineraryID"> 
Restriction base = "string"/> 
</simpleType> 

XsimpleType name = "reservationID" 
Restriction base = "string"/> 
</simpleType> 

• V! ; . < : •- name = "bookingID"> 
Restriction base = "string"/> 
</simpleType> 

<simpleType name = "ticket"> 
Restriction base = "string"/> 
</simpleType> 

<simpleType name = "status"> 
<enumeration value = "created"/> 
<enumeration value = "changed"/> 
<enumeration value = "cancelled"/> 
<enumeration value = "reserved"/> 
Enumeration value = "timedOut"/> 
</simpleType> 



**************** COMPLEX TYPES ************ 

<complexType name = "baseAddress"> 
<sequence> 

<element name = "street" type = "string" 

<element name = "city" type = "string" / 

<element name = "state" type = "string" 

<element name = "ZIP" type = "string" /> 
</sequence> 
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</ complexType> 

<complexType name = "address "> 
-"--nrr • ~rrt> 

<extension base = "xsdl :baseAddress"> 
<sequence> 

<element name = "email" type = "string" /> 
<element name = "phone" type = "string" /> 
</sequence> 
</extension> 
</complexContent> 
</complexType> 



<complexType name = "person"> 

<element name = "name" type = "string" /> 
<element name = "address" type = "xsdl : address" /> 

</sequence> 
</complexType> 

<complexType name = "traveler"> 
-o-i: , -tent> 
<extension base = "xsdl :person"> 

<element name = "travelerlD" type = "string" /> 
</extension> 
</complexContent> 
</complexType> 

<complexType name = "f light "> 
<sequence> 

"startTime" type = "timelnstant" /> 
"startAirport" type = "string" /> 
"destinationTime" type = "timelnstant" /> 
"destinationAirport" type = "string" /> 
"carrier" type = "string" /> 
"cost" type = "float" /> 



<element name = 


<eieme 


nt name = 


<eleme 


nt. name = 


<eleme 




<eleme 


nt name = 


<eleme 




</sequer 




</comple 





plexType name = "leg"> 
<complexContent> 

<extension base = "xsdl : flight "> 
<sequence> 

<element name = "availability" type = "boolean" /> 

</sequence> 

< / c o mp 1 e x C o n t e n t > 
</complexType> 

<complexType name = "itinerary"> 
<sequence> 

<element name = "itinerarylD" type = "xsdl : itinera ryID"/> 
<element name = "leg" 

type = "xsdl: leg" maxOccurs = "unbounded" /> 
<element name = "comments" type = "string" /> 
</ sequence> 
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</complexType> 

<complexType name = "proposedItinerary"> 
-•=nt> 

<extension base = "xsdl : itinerary"> 

<sequence> 

<element name = "totalCost" type = "float" /> 
<element name = "validityDeadline" 
type = "timelnstant" /> 

</complexContent> 
</complexType> 



<complexType name = "trip"> 
<sequence> 

<element name = "startDate" type = "date" /> 
<element name = "startCity" type = "string" /> 
<element name = "arrivalDate" type = "date" /> 
<element name = "destinationAirport" type = "strinc 
<element name = "seatPref erences " 

type = "xsdl : seatPref erences" /> 
<element name = "numberOf Seats" 

type = "nonNegativeInteger"/> 
<element name = "pref erredCarrier " type = "string" 
<element name = "comments" type = "string" /> 

</sequence> 

</'complexType> 



<complexType name = "CCInfo"> 

<element name = "number" type = "string" /> 
<element name = "issuer" type = "string" /> 
<element name = "expiryDate" type = "month" /> 

</sequence> 
' romplexType> 



•CcomplexType name = "statement" 



<e lenient name 
<element name 
<element name 
<element name 
</sequence> 
< / complexT ype > 



"bookingID" type = "xsdl : ID" /> 
"creditCard" type = "xsdl : CCInf o" /> 
"date" type = "date" /> 
"amount" type = "float"/> 
"transactionID" type = "xsdl:ID"/> 



<complexType name = "seatPref erences "> 
<sequence> 

<element name = "class" type = "string"/> 
<element name = "smoking" type = "boolean" /> 
<element name = "window" type = "boolean"/> 

</sequence> 

</complexType> 



<complexType name = "seatDetails"> 
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<element name = "flight" type = "xsdl : f light"/> 
<element name = "preferences" 

type = "xsdl : seatPreferences"/> 

< / c o rnp 1 e x Type > 



<complexType name = 
<complexContent> 
<extension base = 
<sequence> 

<element name = "availability" type = "boolean"/> 



"seatAvailabil ity"> 
"xsdl : seatDetails"> 



</extension> 
</ complexContent> 
</ complexType> 

<complexType name = 
<complexContent> 
<extension base = 
<sequence> 

<element nai 



"seatToRe serve "> 
"xsdl :seatDetails": 
= "notLast" type ; 



</ comp.lexContent> 
</complexType> 

<complexType name = "tickets"> 
<sequence> 

<element name = "ticket" type = "xsdl : ticket" 
minOccurs = "0"/> 

</sequence> 
</complexType> 
schema > 



<! — between Travel Agent and Traveler — > 



<message name = "tripOrderRequest"> 
<documentation> 

Contains the trip information that the traveler sends to the 
travel agent. 
</documentation> 

<part name = "traveler" type = "xsdl : traveler"/> 
<part name = "trip" type = "xsdl : trip" /> 
</message> 

<message name = "tr ipOrderAcknowledgement"> 
<documentation> 

Contains the itinerary that the travel agent proposes to the 
traveler. Itinerary Identification 
</documentation> 



http://www.w3 .org/TR/wsci/ 



5/8/2007 



Web Service Choreography Interface (WSCI) 1.0 



Page 98 of 128 



<part name = "proposedltinerary" type = "xsdl :proposedItinerary"/> 
</message> 

- " l _ ineraryRequest"> 
<documentation> 

Contains the itinerary to be changed 
</ documentation> 

<part name = "itinerary" type = "xsdl : itinerary"/> 

<message name = "changeltineraryConf irmation"> 
<documentation> 

Contains the itinerary changed by the travel agent. 
</documentation> 

<part name = "proposedltinerary" type = "xsdl : proposedltinerary" /> 

</message> 

<message name = "cancelItineraryRequest"> 
<documentation> 

Contains the itinerary to be deleted 
</documentation> 

<part name = " itinerarylD" type = "xsdl : itinerarylD" /> 
</message> 

<message name = "cancelltineraryConf irmation"> 
<documentation> 

Contains the status of the deletion of an itinerary that the 
traveler has requested from the travel agent. 
</documentation> 

<part name = "itinerarylD" type = "xsdl : itinerarylD" /> 
<part name = "status" type = "xsdl : status" /> 
</message> 

s-age name = "reservationRequest"> 

<documentation> 

Contains a request from the traveler to the travel agent 
to reserve the seats for all the legs of an itinerary, 
plus the traveler's credit card information. 

</ documentation 

<part name = "itinerarylD" type = "xsdl : itinerarylD" /> 
<part name = "CCInfo" type = "xsdl : CCInf o" /> 
</message> 

<message name = "reservationConf irmation"> 
<documentation> 

Contains the status of a reservation request that is sent from 
the travel agent to the traveler 
</documentation> 

<part name = " reservationID" type = "xsdl : reservation.ID" /> 
<part name = "status" type = "xsdl : status " /> 
</message> 

<message name = " reservat ionTimeout " > 
<documentation> 

Contains the signal that the reservation of seats has timed out. 
</documentation> 
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<part name = "reservation ID" type = "xsdl : reservati.onID"/> 
<pa.rt name = "status" type = "xsdl : status"/> 
</message> 

<message name = "bookingRequest"> 

<documentation> 

Contains the signal that the traveler confirms a reservation for 
seats 
< / documentation^ 

<part name = "reservationID" type = "xsdl : reservationID" /> 
</message> 

<message name = "bookingConf irmation "> 
<documentation> 

Contains the signal that the travel agent has reserved seats 
</documentation> 

<part name = "bookingID" type = "xsdl : bookingID" /> 
<part name = "status" type = "xsdl : status"/> 



Contains the statement send from the travel agent to a client 
</documentat'ion> 

<part name = "bookingID" type = "xsdl : bookingID" /> 
<part name = "body" type = "xsdl : statement " /> 
</message> 

-- between Travel Agent and Airline --> 

<message name = "seatAvailabilityCheck"> 
<documentation> 

Contains the details of an airplane seat for which the 
availability is to be checked. 
</documentation> 

<part name = " seatDetails" type = "xsdl : seatDetails"/ > 
</message> 

<message name = "seatAvailability"> 
<documentation> 

Contains the confirmation or rejection of the availability of a 
seat. 
</documentation> 

<part name = "seatAvailability" type = "xsdl : seatAvailability"/> 
</message> 

<message name = "seatReservationRequest"> 
<documentation> 

Contains the details of an airplane seat that is to be reserved. 
< /aocumentation> 

<part name = "reservationID" type = "xsdl : reservationID"/> 
<part name = " seatToReserve" type = "xsdl : seatToReserve"/> 
</message> 

<message name = "seatReservationConf irmation"> 
<documentation> 
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Contains the confirmation or rejection regarding the reservation 
of a seat. 
< / documentation 

<part name = " reservationID" type = "xsdl : reservationID" /> 
<part name = "status" type = "xsdl : status"/> 

</message> 

<message name = "ticketOrderRequest"> 
<documentation> 

Contains the confirmation of an airline client that it books 
some seats on behalf of some recipient 
</documentation> 

<part name = "reservationID" type = "xsdl : reservationID"/> 
<part name = "recipient" type = "xsdl :person"/> 
</message> 

<message name = "ticketOrderConf irmation"> 
<documentation> 

Contains the signal that the airline sends to a client that 
indicates the booking success 

</ documentation 

<part name = "bookingID" type = "xsdl : bookingID" /> 
<part name = "status" type = "xsdl : status"/> 
</ mess age > 

<! — between Traveler and Airline — > 

<message name = "tickets"> 
<documentation> 

Contains the e-tickets sent from the airline serviceto the 

traveler service. 
< /documentation 

<part name = "bookingID" element = "xsdl : bookingID" /> 
<part name = "tickets" element = "xsdl : tickets"/> 
</message> 



<mes sage name = " reservat i onCancel 1 ati onReques t> " 

Contains the signal that the sender requests the receiver to 
cancel a reservation 
</documentation> 

<part name = "reservationID" type = "xsdl : reservationID"/> 

</message> 

•'message name = "reservationCancellationResponse>" 
<documentation> 

that has been issued previously 
</documentation> 

<part name = "reservationID" type = "xsdl : reservationID"/> 
<part name = "status" type = "xsdl : status"/;- 
</message> 
</def initions> 
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6. Dynamic Participation 

The interface definition describes the behavioral aspects of a service. The 
previous sections introduce concepts, such as message choreography, message 
correlation, transactions and exception handling, that are important to understand 
how a service behaves in the context of a given message exchange. This section 
introduces another behavioral aspect: the ability of identifying the target service 
when performing an operation which begins with sending a message by means of 
information that is conveyed within the message exchange. 

A message exchange, as described by a WSCI interface, is based on the 
assumption that each Web service will actually play a (named) role in the 
exchange. When modeling, roles are enough to describe the choreography. At 
runtime, though, the identity of the target service when performing an operation 
that begins with sending a message needs to be fully defined for such operation to 
take place. 

Sometimes the identity of the target service does not depend on any information 
described by the WSCI interface; in this case, the action that performs an 
operation that begins with sending a message does not need to be further 
qualified. 

In other cases, though, the identity of the target service is dynamically selected 
based on some criteria that is known at runtime and that depends on information 
described by the WSCI interface, such as message parts. This is equivalent to 
consider that the set of services participating in the exchange can vary during the 
execution of the exchange itself. The ability to model how services can be 
dynamically identified during the message exchange via information conveyed by 
the exchange itself is called dynamic participation: the service's identifier (its 
address or communication end point) can be transmitted as data in a message 
and, optionally, a complex lookup procedure could also be specified. 

In the example presented in Sec tion 5 , the Airline Reservation System 
sends an eTicket to the traveler; either the Airline knows the identity of 
the traveler (in which case the relevant action does not need further 
qualification) or it retrieves the identity from a parts of messages 
exchanged with the Travel Agent. In the latter case, a locator can be 
used. 

The locate and locator elements are the WSCI constructs that realize the 
concept of dynamic participation. These two elements are included as a normative 
extension to the specification. A new namespace 

(http://www.w3.org/2002/07/wsciio/iocate namespace) has been introduced to 
explicitly separate the WSCI core elements from the normative extension that 
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includes the definitions of the locate and locator elements. Not all WSCI 
implementations would necessarily support dynamic participation. 

Note: A WSCI implementation that ignores 

the locate and locator elements, but 
supports all other WSCI elements, is 
considered WSCI-compliant. An 
implementation that understands the locate 
and locator elements is considered 
compliant to the extended behavior. 

6.1 Locate 

The locate element is used to identify a service against which the action will be 
performed (target service). It is defined as an optional extension element of the 
action element. At most one locate element can be specified for an action. The 
locate element identifies the service to which the message will be sent. An action 
that is receiving a message does not require any locate element since it is 
performed by the service whose interface is under consideration. 

The locate element specifies which properties and/or mechanism are used to 
identify a particular target service. In some situations (replay-to address and 
redirection, for instance) the URI of the target service can be simply specified via a 
property. In other situations, more complex locator mechanisms (e.g. UDDI 
lookup) might be used to resolve the service. 

By knowing the properties used to locate the service it is possible to understand 
how, changing the value of these properties, the behavior of the corresponding 
services is affected. 

The syntax of the locate element is: 

<locate 

property = list of QName 



The property attribute lists all properties used to identify a particular service. A 
property is referenced using a qualified name. The property attribute is optional. 

The locator attribute references a locator element (which, in turn, describes the 
mechanism that, by means of the properties listed in the locate element, is able to 
identify the service). The locator is referenced using a qualified name. Thus, it is 
possible to use locators defined in a namespace other than the namespace used 
for the interface definition. The locator attribute is optional. 



http://www.w3.org/TR7wsci/ 



5/8/2007 



Web Service Choreography Interface (WSCI) 1.0 



Page 103 of 128 



A locate element must specify at least one of these two attributes. If the locator 
attribute is omitted exactly one property must be specified which value is a URI of 
the service. If the property attribute is omitted the locate element must specify the 
locator attribute. In this case the locator element is not dependent on any property 
and the target service is assumed to be always the same (the service is specified 
by the locator definition). If at least one property is given and a locator attribute is 
specified, it is assumed that the locator mechanism uses the property list to 
resolve the service. The locator mechanism is required if the service is not 
identified by a URI. 

6.2 Locator 

The locator element specifies a mechanism used to identify a particular service. 
The syntax of the locator element is: 

<locator 

name = NCName 

property = list of QName 

/extension at~ribute}> 

Con ten t : ( documentation?, 

{extension element }) 
</locator> 

The name attribute provides a name for the locator. This attribute is mandatory. The 
name must be unique among names of locators defined in the same namespace. 

The property attribute lists all properties used to resolve the service. This property 
list defines the list of formal parameters used by the locator mechanism. The 
property list in the locate element defines the actual parameters for that 
mechanism. The properties in the locator element are given values from the 
corresponding properties listed in the locate element, using the same order. A 
locator element may include the documentation element, which contains arbitrary 
text. 

The definition of the mechanism used to identify a specific service is out of the 
scope of WSCI and can be addressed by existing and future specifications. For 
that reason the locator element is defined as an extensible element. A WSCI 
implementation is not required to understand how the locator mechanism (e.g. 
UDDI lookup) works. A locator element must include exactly one extension 
element and may include zero or more extension attributes that can be used to 
provide additional information for the purpose of locating services. 

A locator definition is not limited to a specific interface definition. The locator 
element is a WSCI top-level element. 

Example. This example extends the example given in Section 5 by introducing the 
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locate element. The final part of the airline ticket reservation process 
encompasses the booking of seats activity. The Traveler initiates this activity 
sending the reservation confirmation to the Travel Agent, which, after that, 
requests from the Airline Reservation System to book the seats. The notification of 
the successful booking is sent to Travel Agent and the confirmation of the issued 
tickets is sent to the Traveler. 



The interface definition of the Airline Reservation System given in Section 5.4.3 
does not identify the service to whom the confirmation of the issued tickets will be 
sent. Consequently, the Travel Agent cannot conclude, from the interface 
definition of the Airline Reservation System, that the message will be sent to the 
Traveler that initiated the* booking of seats. The Traveler's name and email 
address are conveyed in the bookingRequest message sent to the Airline 
Reservation System by the Travel Agent. The Airline Reservation System does not 
previously know any specific traveler. 

This example provides a modified version of the Airline interface. The sendTickets 
action uses the locate element to identify the Traveler to whom the message will 
be sent. The locate element uses the repiy-ToAddress property which value is 
obtained from the incoming bookingRequest message. The accompanying selector 
definition is given below; the complex type traveler is defined in Section 5.7. 

<?xml version = "1.0" ?> 

<wsdl :def initions name = "WSCI_Def initions" 

targetNamespace = "http : //example . com/ consumer /definitions" 
xmlns :tns = "http: //example . com/ consumer/definitions" 
xmlns :wsdl = "http://schemas.xmlsoap.org/wsdl/" 
xmlns = "http://www.w3.org/2002/07/wscil0"> 

<wsdl: import namespace = "http://example.com/consumer/definitions" 
location = "http://example.com/messages.wsdl" /> 



Definitions of selectors 
section 5.7 are omitted. 



<selector property = "tns : replyToAddress" 
type = "tns : traveler" 
xpath = ". /email/text () " /> 

</wsdl :def initions> 

<?xml version = "1.0" ?> 

<wsdl : definitions name = "Airline" 

targetNamespace = "http: //example . com/ consumer/airline" 
xmlns = "http://www.w3.org/2002/07/wscil0" 
xmlns :def s = "http: //example. com/consumer/definitions" 
xmlns: tns = "http://example.com/consumer/airline" 
xmlns :wsdl = "http : //schemas . <rsdl/" 
xmlns twscil = "http://www.w3.org/2002/07/wscil0/locate" 
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<wsdl : import namespace = "http://example.com/consumer/definitions" 
location = "http://example.com/messages.wsdl" /> 

<wsdl : import namespace = "http://example.com/consumer/definitions" 
location = "http://example.com/definitions.wsci" /> 



* AIRLINE INTERFACE " 



<process name="Verif ySeats" i nst ant i at ion= "message "> 
<action name="Verif ySeatAvail ability " 
role="tns : Airline" 

operation="tns:AirlineToTA/VerifySeatAvailability"/> 
</process> 

<process name="PlanAndBookTrip" instantiation= "message" > 
<sequence> 

transaction name = "seat-Reservation" 

<compensation> 

<action name = "NotifyOf Cancellation" 
role = "tns : Airline" 

operation = "tns : AirlineToTA/NotifyOfCancellation"/> 
</compensation> 
</transaction> 
</ context> 

operation="tns:AirlineToTA/ReserveSeat"/> 

<while name="ReserveSeats"> 

<condition>def s : notLastSeat</condition> 
Oct ion name="ReserveNextSeat" 
role ="tns : Airline" 

operation="tns : AirlineToTA/ReserveSeat"> 
<correla.te correlation = " : " /> 

</action> 
</while> 
</sequence> 

<sequence> 
<context> 
<exception> 

<onTimeout property = "tns : expiryTime" 
type = "duration" 

reference="tns : ReserveSeats@end"> 
<compensate name = "CompensateReservation" 
transaction "/> 

</onTimeout> 
</exception> 
</context> 

<choice> 
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<onMessage> 

<action name = "ReceiveCancellationRequest" 
role ="tns : Airline" 

operation="tns:AirlineToTA/CancelReservation"> 
<correlate correlation="def s : reservationCorrelation"/> 

<compensate name = "CompensateReservation" 
transaction = "seatReservation"/> 

</onMessage> 

<nMessage> 

Oct ion name="Perf ormBooking" 
role ="tns : Airline" 

operation="tns : AirlineToTA/BookSeats"> 
<correlate correlation="def s : reservationCorrelation"/> 
</action> 

<action name="SendTickets" 
role ="tns:Airline" 

operation="tns:AirlineToTraveler/SendTickets"> 
<wscil : locate property = "defs: eplyToAdd ass" /> 
</action> 
</ onMessage> 
</choice> 
</sequence> 
</process> 
</interface> 



7. Future Work 

WSCI is a work in progress; as such there areas, which we feel, will be expanded 
on as the specification matures. 

7.1 Exclusion Groups 

For a generic model we think that it might be useful to have a possibility to specify 
properties ("exclusion groups") indicating services that must be excluded from a 
set of services against the action can be performed. Our first thought was that 
these services should be specified using a single property whose value is a URI 
(but no restriction must be made). For example, exclusion groups can be used to 
specify that a service against the action performed is not the service used in a 
previous action (step). In this case, we assume that a locator has the name and 
instantiates property with the same name whose value is the service identifier (e.g. 
URI). The service used in a previous action (step) can be referenced using the 
name of the corresponding locator. 

7.2 Web based Collaboration 
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At the time of submission of this standard the web services stack is in very early 
stages of evolution. 

We view the ultimate goal of web services as enabling web-based collaboration. 

As stated in the introduction, and as re-illustrated here, we see layers above WSCI 
defining the aspects of such collaborations, and WSCI in essence reifying the 
interface of each participant in such a collaboration. 



, s *r dU I ' L.IVL i 

Process/Collaboration 
definition 



wsc 

Message Choreograph}' 

C f t ! 



As the collaboration layer(s) of the web services stack evolve to define aspects 
such as Contract, State, Role, and Rights and Obligations of Participants, WSCI 
will need to evolve in parallel to facilitate the mapping of WSCI elements to these 
anticipated elements of the Collaboration layer(s). For instance, we expect the 
current Role element evolving to map to a Role at the collaboration level, and the 
Process element to map to a Process element at the collaboration level. As these 
mappings get created, they may require syntax changes to either the WSCI 
specification and/or the Collaboration specification. 

7.3 Global Model 

In this version of the WSCI specification the global model consists of mappings of 
operations of one web service to operations of another web service. This choice 
was made to preserve the close relationship to the web service description 
languages, such as WSDL, where atomic web service operations are described. 
As the higher layers of the web service stack mature, we anticipate that the focus 
will be more on the collaboration aspects of the global model. This would mean a 
focus more on describing the interaction between two (or more) participants, and 
less on the lower level one sided operation definitions. Most likely future work will 
include a global mapping of WSCI actions to each other, and an evolution of the 
relationship between roles and actions. 

With the current specification the global model assumes a pretty tight coupling 
between the WSCI action and the WSDL operation. This, to a degree, limits the 
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ability of a given WSDL operation to be re-used in multiple actions, as care has to 
be given to the unique naming of the actions and operations. Lifting the level of the 
global model up to the action level would be a first step towards a looser coupling 
and a greater re-usability of operations across multiple actions. 

However, embarking on this work would be premature until the evolving 
collaboration models are more stable and well known. 



8. Appendix 

8.1 Known Issues 

The current version of the WSCI specification and, specifically, the design of the 
relationship between WSCI and WSDL, is based on the W3C acknowledged 
submission of the WSDL specification. It is acknowledged that the WSDL 
specification may evolve in the future and, although the relationship between 
WSCI and WSDL is deliberately loosely coupled, each future change to the WSDL 
specification will be reviewed as to its potential change to WSCI. 

8.2 References 
[WSDL] 

Web Services Description Language (WSDL) 1.1, Erik Christensen, 
Francisco Curbera, Greg Meredith, Sanjiva Weerawarana, Editors. World 
Wide Web Consortium, 15 March 2001. WSDL 1.1 is available at 
http://www.w3.org/TR/2001/NOTE-wsdl-20010315. 
[RFC 2119] 

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. 
IETF, March 1997. RFC 21 19 is available at 
http://www.normos.org/ietf/rfc/rfc21 1 9.txt. 
[RFC 2396] 

Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. 
Fielding, L. Masinter. IETF, August 1998. RFC 2396 is available at 
http://www.normos.org/ietf/rfc/rfc2396.txt 
[XML Schema 1] 

XML Schema Part 1 : Structures, Henry S. Thompson, David Beech, Murray 
Maloney, Noah Mendelsohn, Editors. World Wide Web Consortium, 2 May 
2001. This version of the XML Schema Part 1 recommendation is available 
at http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/. The latest 
version of XML Schema Part 1 is available at 
http://www.w3.org/TR/xmlschema-1/. 
[XML Schema 2] 

XML. Schema Part 2: Datatypes, Paul V. Biron, Ashok Malhotra, Editors. 
World Wide Web Consortium, 2 May 2001 . This version of the XML Schema 
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Part 2 recommendation is available at http://www.w3.org/TR/2001/REC- 
xmlschema-1 -2001 0502/. The latest version of XML Schema Part 2 is 
available at http://www.w3.org/TR/xmlschema-2/. 
[XPATH] 

XML Pat h Languag e (XPath) Version 1.0 , James Clark, Steve DeRose, 
Editors. World Wide Web Consortium, 16 November 1999. This version of 
XPath 1.0 recommendation is available at http://www.w3.org/TR/1999/REC- 
xpath-19991 116. The latest version of XPath 1.0 is available at 
http://www.w3.org/TR/xpath. 

8.3 Glossary 

This glossary contains definitions of key terms used within this WSCI specification. 
The definitions are as seen from a WSCI perspective. Some of these terms may 
have different meaning in other environments. 

Included in this glossary are terms that have important conceptual content for the 
understanding of this specification. Not included in this glossary are the names of 
more specific WSCI language constructs. For discussion of such language 
constructs, see Section 3, 

This glossary is in alphabetic order. See Section 2 for an introduction to the 
concepts in logical order. 

Action: An atomic activity that describes the manner in which a service performs a 
single atomic message exchange as defined, for instance, by a WSDL operation. 

Activity: Any of the WSCI language constructs that describe simple or complex 
behavior. An activity is the basic building block for defining behavior within a 
process. 

Atomic Activity: An activity definition that cannot be decomposed into further 
activities. It represents an atomic unit of work. There are two types of atomic 
activities: Action and Delay. 

Activity Instance: An Activity being executed. 

Activity Set: Defines a set of activities together with the context in which they are 
performed. An Activity Set is a modeling artifact mainly used to describe Complex 
Activities; it does not correspond directly to any WSCI language construct. 

Choreography: Describes temporal and/or logical dependencies among 
Activities. 

Collaboration: The act of a set of participants, for instance a set of Web services, 
working together in complex relationships to meet a common goal. Definition of 
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Collaboration requires the definition of roles, responsibilities, contracts, artifacts, 
state management and state transitions binding involving all the participants' 
involved parties. Definition of Collaboration is out of the scope of WSCI, but it is 
assumed that such a definition exists formally or informally. 

Compensation: A transaction may declare a set of compensating activities that 
are to be executed when a successfully completed transaction needs to be 
undone. Compensation describes only the externally observable activities required 
to undo the transaction; it does not describe how the transaction is undone by the 
implementation. 

Complex Activity: An Activity definition that is composed of other Activities. A 
complex activity defines a choreography for the activities of which it is composed. 

Context: declares characteristics that affect the execution of a particular set of 
activities, in terms of local properties, local process definitions, transactional 
characteristics and exceptional behavior. Contexts can be nested to an arbitrary 
level. 

Conversation: The message traffic associated with one execution of a 
choreography (or part thereof), as a service interacts with other services to 
execute that choreography. 

Correlation: The concept of correlation describes how conversations are 
structured and which properties must be exchanged to retain the semantic 
consistency of the conversation. 

Event: The occurrence of an event that can be handled by a WSCI event handler. 
WSCI supports the following event types: receipt of a message, occurrence of a 
timeout and occurrence of a fault. 

Exception: Declares the exceptional behavior that may be exhibited by a Service 
at a given point in a choreography. 

Execution Context: describes the environment in which sets of activities are 
performed. It contains the declarations of the context pertaining to the set of 
activities, plus, recursively, the declarations inherited from the execution context of 
the activity containing this set of activities. 

Fault: An event that expresses a failure in performing an action or activity. Event 
handlers declared in the same or parent contexts may catch the fault event. 

Global Model: Describes a multi-participant view of the overall message 
exchange as a collection of links between the operations of communicating 
services. 
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Interface: Describes the observable behavior of a service as it participates in a 
message Exchange. 

Message Correlation: A mechanism by which a message received by a service is 
associated with a particular conversation. See also Correlation. 

Nested Process: A process that is local to a context. A nested process is defined 
within the context of complex activities and can be referenced only from within the 
context defining it. 

Operation: An abstract description of an atomic message exchange supported by 
the service. In the current specification, the Operation maps to WSDL operations. 

Process: A process defines one activity set that is performed exactly once, and all 
activities in that activity set are performed in sequential order. Referencing it from 
other processes or activities can reuse the behavior described by a process. 

Process Instance: A process being executed. 

Role: The identification of some behavior within a process definition. The role 
attribute associates a role name with WSCI actions that represent that behavior. 

Service: An instance of a Service Type, i.e. the actual implementation of a Service 
exhibiting the behavior described for the service type. See also Web Service 
below. 

Service type: Identifies a class of Web services that exhibit the same behavior 
with respect to a given message exchange. 

Thread: A portion of a program that can run independently of and concurrently 
with other portions of the program. 

Top-level process: These processes are defined at the interface level and can be 
referenced from everywhere within the interface. 

Transaction: Transactions are used to model the behavior of a service asserting 
that a certain number of activities should be treated as a single unit of work; a 
service uses a transaction to communicate to other services its ability to either 
completely execute those activity or to restore the consistent state prior to the 
execution. 

Transaction Instance: A transaction being executed. 

Web Service: Web services are a key component of the emerging, loosely 
coupled, Web-based computing architecture. A Web service is an autonomous, 
well-defined, standards-based component that can be accessed via established 



http://www.w3.org/TR/wsci/ 



5/8/2007 



Web Service Choreography Interface (WSCI) 1 .0 Page 1 1 2 of 1 28 



Web-based protocols. 

8.4 WSCI Schema 



Note: The following WSCI schemas have 
been validated using today's popular XML 
tools. 



8.4.1 Standard 

<xsd: schema targetNamespace="http : //www . w3 . org/2 002 / 07/ ws- 
xmlns : xsd="http : //www . w3 . org/2001 /XMLSchema" 
xmln s : ws c i= " ht tp : / / www .w3.org/2002/07/wscil0" 
elementFormDefault="qualif ied" 
blockDefault="#all"> 

<!-- Simple type definitions — > 

<xsd:simpleType name="listOfQName"> 
<xsd:annotation> 

<xsd : documentations 

Simple type representing a list of QNames. 
</xsd: documentation> 
</xsd: annotation> 
<xsd: list itemType="xsd:QName"/>* 
</xsd : simpleType> 

<xsd: simpleType name="transactionType"> 

<xsd : documentation> 

Allowed transaction types. 
</xsd:documentation> 
</xsd:annotation> 

<xsd: restriction base="xsd: string"> 

<xsd: enumeration value="atomic"/> 

<xsd : enumeration value="open"/> 
</xsd: restriction> 
</xsd : sirnpleType> 

<xsd: simpleType name=" instant ia t ion Type "> 
<xsd: annot.ation> 

<xsd: documentations 

Allowed instantiation types: message or other. 
</ xsd: documentations 
</xsd : annotation> 

<xsd:restriction base="xsd: string's 

<xsd: enumeration value="message"/> 

<xsd: enumeration value="other "/> 
</xsd: restrict ion> 
</xsd:simpleType> 

<xsd: simpleType name="timeConstraintType"> 
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<xsd: annotation> 

<xsd : documentation 

Time constraint type: duration < 

</xsd : documentations 
</xsd: annotations 

<xsd: restriction base="xsd: string"> 
<xsd: enumeration value="duration". 

</xsd : s imp I eType> 



/ ^ ji i - " ; l dipe"> 

<xsd: annotation> 

<xsd: documentations 

Simple type representing a WSDL operation name 
(QName/NCName) . 
</xsd: documentation> 
</xsd: annotation> 

<xsd : restriction base="xsd: string's 
^<xsd:pattern value=" [ \i- [ : ] ] [ \c- [:]]*:[ \i- [:] ] [\c- [:]]*/ [\i- [:] ] [\c- 

</xsd: simpleType> 



<xsd: simpleType name="opNameList"> 
<xsd: annotation> 

<xsd: documentations 

Simple type representing a list of WSDL 
operation names . 
</xsd: documentations 
</xsd : annotation> 

i 1 - i r m 

</xsd: simpleType> 

<xsd: simpleType name="twoOpNames"> 

<xsd : documentations 

Simple type representing two WSDL operation names. 
</xsd: documentations 
</xsd : annotatiors 

<xsd: restriction base="wsci : opNameList"> 

<xsd: length value="2"/> 
</xsd:restriction> 
</xsd: simpleType> 

<xsd : simpleType name="expression"> 
<xsd: annotation > 

<xsd: documentations 

Simple type representing an expression, 
possibly but not necessarily XPath. 
Cannot hold an empty string. 
</xsd : documentations 
</xsd: annotatiors 

<xsd: restriction base="xsd: string's 

<xsd:minLength value="l"/> 
</xsd: restriction> 
</xsd: simpleType> 
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: ii it t i 11 " 

<xsd: annotation> 

<xsd: documentation> 

Time reference: a property name or an activity name 

plus the @ start or @end designator. 
</xsd:documentation> 

<xsd: restriction base="xsd: string"> 

<xsd: pattern value=" [:]] [\c- [:]]*: [:]] [\c- [:]] * (@start | Send) 

</xsd:simpleType> 

<!-- Complex type and element definitions (generic) --> 

<xsd: complexType name="documented"> 
<xsd: annotation> 

This type is extended by all elements that 
allow documentation. 

</xsd:annotation> 
<xsci: sequence> 

<xsd: element ref="wsci : documentation" minOccurs=" 0 " maxOccurs=" 1 " /> 
</xsd: sequence> 
</xsd: complexType> 

<xsd: element name="documentation"> 
<xsd: annotation 

<xsd : documentation> 

This element allows documentation to appear as 
mixed content using any schema. 
</xsd : documentation> 
</xsd:annotation> 
<xsd: complexType mixed="true"> 
<xsd: sequence> 

<xsd: any namespace="##other" proces sCon ten ts=" skip" 
minOccurs="0" maxOccur s=" unbounded" /> 
</xsd : sequence> 
</xsd: complexType> 
</xsd : element> 

<xsd: element name=" selector" type="wsci : selector" /> 

<xsd : complexType name=" selector "> 
<xsd : annotation> 

<xsd : documentation> 

A property selector. Defines how a property value is 
instantiated from a message part given the type 
definition of the message part and an optional XPath 
expression. The element and type attributes are mutually 
exclusive. At least one type reference must be used. 
</xsd: documentation 
</xsd : annotation 
< x s d : c o rap i e x C ontent > 

<xsd: extension base="wsci : documented" > 
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<xsd: sequence> 

<xsd:any namespace="##other " processContents="strict" 
minOccurs="0" maxOccurs="l"/> 
</xsd: sequence> 

<xsd: attribute name="property" type="xsd:QName" 

use="required"/> 
<xsd: attribute name="element" type="xsd:QName" 

use="optional"/> 
<xsd: attribute name="type" type="xsd: QName" 

use= "optional "/> 
<xsd: attribute name="xpath" type="wsci : expression" 

use="optional"/> 
<xsd:anyAttribute namespace="##other" 

processContents=" strict "/> 

</ xsd: comp lexContent> 
</xsd: complexType> 

<xsd : element name="corre!ation" type="wsci : correlation"/> 

<xsd : complexType name="correlation"> 
<xsd: annotation> 

<xsd: documentation 

A correlation definition. Names a correlation and 
specifies the properties that are used to identify the 
correlation instance. 
</xsd:documentation> 
</xsd:annotation> 
<xsd: complexContent> 

<xsd:extension base="wsci : documented" > 

<xsd: attribute name="name" type="xsd:NCName" 

use=" required" /> 
<xsd : attribute name="property" type="wsci : listOf QName" 

use=" required" /> 
<xsd: attribute name="extends" type=" xsd: QName" 
use=" optional "/> 

</xsd : complexType> 

<xsd: complexType name="correlate"> 
<xsd: anno tat ion> 

<xsd : documentation> 

Correlates an action by referencing the correlation 
definition and indicating whether that action is part 
of the correlation instantiation or part of an existing 
correlation instance. 
</xsd: documentation 

<xsd: attribute name="correlation" type="xsd: QName" 

us e=" required" /> 
<xsd: attribute name=" instantiation" t ype=" xsd : boolean" 

use=" optional" def ault=" false "/> 
</xsd : complexType> 

<!-- Generic type definitions used by activity types --> 
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<xsci : complexType name="activity"> 
<xsd:annotation> 

<xsd:documentation> 

The base type for all activity elements. It defines 
the optional name attribute and includes the 
documentation element in the contents. 
</xsd : documentations 
</xsd:annotation> 
<xsd : complexContent> 

<xsd : extension base="wsci : documented"> 

<xsd : attribute name="name" type="xsd:NCName" 
use="optional"/> 

</xsd: extension> 
</xsd: complexContent> 
</xsd: complexType> 

<xsd: element name=" activity" abstract="true" type="wsci : activity" /> 

<xsd : group name="activitySet"> 
<xsd: annotation> 

<xsd : documentation> 

A set of activities that perform in the same context. 
Allows the optional context element, and zero or more 
activities from all the activity types. 
</xsd: documentation> 
</ xsd : annotation> 
<xsd: sequence> 

<xsd:element name="context" type="wsci : context" 
minOccurs="0" maxOccurs="l"> 
<xsd: key name="contextProcessConstraint"> 
<xsd: selector xpath=" . /wsci :process"/> 
<xsd: field xpath="@name"/> 
</xsd: key> 

<xsd:key name="contextPropertyConstraint"> 

<xsd: seiec-cr xpath=" . /wsci : property" /> 

<xsd: field xpath="@name"/> 
</xsd: key> 
</xsd : element> 

<xsd: choice minOccurs="l" maxOccur s= " unbounded" > 
<xsd:element name="action" type="wsci : action" /> 
<xsd:element name="all" type="wsci : all" /> 
<xsd: element name- "call" type="wsci : call"/> 
<xsd: element name- "choice" type="wsci : choice";- 
<xsd: unique name="choiceFaultConstraint"> 
<xsd: selector xpath=" . /'wsci : onFault" /> 
<xsd: field xpath="@code" /> 

<xsd: key name="choiceTimeoutConstraint"> 

<xsd: selector xpath=" . /wsci : onTimeout"/> 

<xsd : field xpath="@property"/> 
</xsd:key> 
</xsd: element> 

<xsd : element name="compensate" 

type="wsci : compensate"/> 
<xsd: element name="delay" type="wsci : delay" /> 
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<xsd: element name="empty" type="wsci : empty " /> 
<xsd : element name- "fault" type="wsci : f ault"/> 
<xsd:element name=" f oreach" type="wsci : f oreach"/> 
<xsd:element name="join" type="wsci : join"/> 
<xsd : element narae= " sequence " type="wsci : sequence" /> 
<xsd: element name="spawn" type="wsci : spawn" /> 
<xsd: element name="switch" type="wsci : switch"> 

<xsd: key name="switchConditionConstraint"> 
<xsd: selector xpath=" ./wsci :case"/> 
<xsd: field xpath=" . /wsci : condition" /> 

</xsd:key> 
</xsd : element> 

<xsd:element name="until" type="wsci : unti 1 " /> 
<xsd:element name="while" type="wsci :while"/> 
<xsd: element ref ="wsci : activity" /> 
</xsd: choice> 
</xsd: sequence> 
</xsd : group> 

<xsd : complexType name="condition"> 

<xsd: documentations 

A condition expression. The expression is given 
as character data, the common understanding is 
that of an XPath expression. Extension attributes 
can be used to express other semantics. 
</xsd : documentation 
</xsd: annotation> 
<xsd: simpleContent> 

<xsd : extension base="wsci : expression's 
<xsd : anyAt tribute namespace="##other" 

processContents=" strict "/> 

</xsd: extension 
</xsd. : simpleContent> 
</xsd : complexType> 

<xsd: complexType name="eventHandler"> 
<xsd: annotation> 

<xsd : documentations 

The base type for all activity elements. It defines 
the optional name attribute and includes the 
documentation element in the contents. 

</xsd:annotation> 
<xsd : complexContent> 

<xsd: extension base="wsci: documented" /> 
</xsd : compiexCcntent> 
</ xsd : complexType> 

<xsd : complexType name="onMessage"> 
<xsd:annotation> 

<xsd: documentations 

An event handler that is triggered by an 
inbound message. The first action activity 
that precedes the activity set must complete 
for this activity set to perform. 
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</xsd : documentation 
</xsd : annotation> 
<xsd : complexContent> 

<xsd: extension base="wsci :eventHandler"> 
<xsd: sequence> 

<xsd: element name="action" t ype="wsci : action" /> 
<xsd : group ref="wsci : activitySet" / > 
</xsd : sequence> 
</xsd:extension> 
</xsd: complexContent> 
</xsd : complexType> 

<xsd: complexType name="onTimeout"> 
<xsd : annotation> 

<xsd : documentat ion> 

An event handler that is triggered by a timeout. 
</xsd: documentat ion> 
</xsd: annotation> 
<xsd: complexContent> 

<xsd : extension base="wsci : eventHandler"> 
<xsd: group ref ="wsci : activitySet" /> 
<xsd: attribute name="property" type="xsd:QName" 

use=" required" /> 
<xsd : attribute name="type" type="wsci : timeConst rain t Type" 

use=" optional" def ault= "duration "/> 
<xsd : attribute name="ref erence" type="wsci : timeRef erence" 
use="optional" /> 

</xsd:extension> 
</xsd: complexContent> 
</xsd: complexType> 

<xsd: complexType name="onFault"> 
<xsd: annotation> 

<xsd: documentat ion> 

An event handler that is triggered by a fault. 
</xsd : documentation:' 
</xsd:annotation> 
<xsd: complexContent> 

<xsd : extension base="wsci : eventHandler "> 
<xsd: group ref="wsci : activitySet" /> 
<xsd: attribute name="code" type="xsd : QName" 
use=" optional" /> 



</xsd: complexContent> 
</xsd: complexType> 

<xsd: group name="anyEvent"> 
<xsd : annotation> 

An event handler: onMessage, onTimeout or onFault. 
</xsd: documentation^ 
</xsd:annotation> 

<xsd: element name="onMessage" type " : essage"/> 
<xsd: element name="onTimeout" type="wsci : onTimeout" /> 
<xsd: element name="onFault" type="wsci : onFault"/> 
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</xsd:choice> 
</xsd : group> 

<! — Type definitions for activities — > 

<xsd: cornplexType name="action"> 
<xsd: annotation> 

<xsd:documentation> 

The action activity references an abstract operation 
definition against which the action will occur. 
It also identifies which correlations are used to 
associate a message instance with an activity context. 
</xsd: documentation 
</xsd: annotation> 
<xsd: complexContent> 

<xsd: extension base="wsci : activity"> 
<xsd: sequence> 

<xsd: element name="correlate" type="wsci : correlate" 

minOccurs="0" maxOccurs="unbounded" /> 
<xsd: element name="call" type="wsci : call" 

minOccurs="0" maxOccurs=" 1 " /> 
<xsd:any namespace="##other" processContents="strict" 
minOccurs="0" maxOccurs="unbounded" /> 
</xsd: sequence> 

<xsd: attribute name="operation" type="wsci : opKame" 

use="optional"/> 
<xsd: attribute name="role" type="xsd:QName" 

use="optional"/> 
<xsd: anyAttribute namespace="##other" 

processContents=" strict "/> 

</xsd: extension> 
</xsd:complexContent> 



<xsd : annotation> 

<xsd:documentation> 

Performs all the activities in any order. 
</xsd : documentation> 

<xsd: complexContent> 

<xsd : extension base="wsci : activity"> 
<xsd: group ref="wsci : activitySet"/> 

</xsd:complexContent> 
</ xsd : complexType> 

<xsd : cornplexType name="call"> 
<xsd:annotation> 

<xsd: documentations- 
Invokes a process and waits for it complete. 

</xsd: annotation> 
<xsd : complexContent> 

<xsd: extension base="wsci : activity "> 
<xsd: sequence/> 
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<xsd: attribute name="process" type= " xsd : NCName " 
use="required"/> 

</xsd: extension> 
</xsd: complexContent> 
</xsd: complexType> 

name="choice"> 

<xsd:annotation> 

<xsd: documentation 

Selects one activity set and performs it. 
The activity set is selected by an event 
handler or time onMessage, onTimeout or 
onFault. At least two event handlers must 
be specified. 
</ xsd : documentation 
</xsd:annotation> 
<xsd: complexContent> 

<xsd: extension base="wsci : activity"> 
<xsd: group ref ="wsci : anyEvent" 

minOccurs="2" maxOccurs=" unbounded" /> 
= : e >- =ion> 
</xsd: complexContent> 



<xsd : complexType name="compensate"> 
<xsd: annotation> 

<xsd: documentation 

Compensate for all completed instances of the 
named transaction that has not been compensated 
for yet. 
</xsd: documentation> 

<xsd : complexContent> 

<xsd: extension base="wsci : activity"> 
<xsd: sequence/> 

<xsd : attribute name=" transact ion" type=" xsd: NCName" 
use=" required" /> 

</xsd:extension> 
</xsd : complexContent> 
</xsd: complexType> 

<xsd: complexType name=" delay" > 
<xsd : annotation> 

<xsd: documentation> 

Represents the passage of time. 
</xsd: documentation 
</xsd : annotation> 
<xsd : complexContent> 

<xsd: extension base="wsci :activity"> 

<xsd: attribute name="property" type="xsd : QName" 

<xsd : attribute name="type" type="wsci : timeConstraintType" 
use="optional" def ault="duration" /> 

<xsd : attribute name="ref erence" type="wsci : timeRef erence" 
use="optional"/> 

</xsd: extension> 
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</ xsd: complexContent> 
</xsd : complexType> 

<xsd: complexType name=" empty" > 
<xsd :annotation> 

<xsd: documentation> 

An activity that does nothing. 
</xsd : documentation> 

<xsd: complexContent> 

<xsd: extension base="wsci : activity"/> 
</xsd : complexContent> 
</xsd:complexType> 

<xsd: complexType name="f ault"> 
<xsd : annotation> 

<xsd: documentation> 

Signals a fault in the process and branches into 
exception handling. 
</xsd : documentation^ 
</xsd: annotation 
<xsd: complexContent> 

<xsd : extension base="wsci : activity"> 

<xsd : attribute name="code" type="xsd:QName" 
use=" required" /> 

</xsd : extension> 
</xsd:complexContent> 
</xsd: complexType> 

<xsd: complexType name=" f oreach"> 



Repeats the activity set for each item in 
the pre-selected item list. 

</xsd : annotation> 
<xsd: complexContent> 

<xsd: extension base="wsci : activity "> 
<xsd : group ref="wsci : activitySet"/> 

<xsd : attribute name="select" type="wsci : expression" 
use="required"/> 

</xsd : extension> 
</xsd: comp.lexContent> 
</xsd: complexType> 

<xsd: complexType name=" join"> 
<xsd : annotation> 

<xsd : documentation^ 

Waits for all nested pro 
</xsd: documentation </xs 
<xsd : complexContent> 

<xsd: extension base="wsci : activity's 
<xsd: sequence/> 

<xsd : attribute name="process" type="xsd:NCName" 
use=" required" /> 

</xsci : extension > 
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</xsd: complexContent> 
</xsd: complexType> 

<xsd: complexType name=" sequence"> 
<xsd : annotation> 

<xsd: documentations 

Performs all the activities in sequence. 
</xsd : documentation^ 
</xsd: annotation> 
<xsd: complexContent> 

<xsd: extension base="wsci : activity's 
<xsd : group ref ="wsci : activi tySet " /> 

</xsd : complexContent> 
</xsd: complexType> 

<xsd : complexType name="spawn"> 
<xsd: annotation 

<xsd: documentation> 

Instantiates a process without waiting for 
it to complete. 

</xsd:annotation> 
<xsd : complexContent> 

<xsd: extension base="wsci : activity's 
<xsd: sequence/> 

<xsd : attribute name="process " type="xsd:NCName" 
use="required"/> 

</xsd:extension> 
</xsd : complexContent> 
</xsd : complexType> 

<xsd: complexType name=" switch" > 
<xsd:annotation> 

<xsd:documentation> 

Selects one activity set and performs it. 
The condition of each case are evaluated in 
order and the first condition to be met (evaluate 
to true) will cause the activity set of that case 
to be performed and the switch activity to complete. 
If no condition is met, the activity set of the 
default case is performed and the switch activity 
completes. If the default case is missing, the 
switch activity completes immediately. 



sd: complexContent> 

<xsd : extension base="wsci : activity's 
<xsd : sequence> 

<xsd: element name="case" 

minOccurs="l" maxOccurs=" unbounded "> 
<xsd : complexType> 

<xsd : complexContent> 

<xsd : extension base="wsci : documented "> 
<xsd: sequence> 

<xsd: element name=" condition" 
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type="wsci : condition" /> 
<xsd:group ref="wsci : activitySet"/> 
</xsd: sequence> 
</'xsd: extension> 
</xsd: complexContent> 
</xsd: complexType> 
</xsd:elernent> 

minOccurs=" 0 " maxOccur s= " 1 " > 
<xsd : complexType> 

<xsd : complexContent> 

<xsd: extension base="wsci : documented"> 

<xsd: group ref="wsci : activitySet " /> 
</xsd : extension> 
</xsd: complexContent> 
</xsd: complexType> 
</xsd : element> 
</xsd: sequence> 
</xsd: extension> 
</xsd: complexContent> 
</xsd: complexType> 

<xsd: complexType name="until"> 
<xsd: annotation> 

<xsd: documentation 

Repeats the activity set until the condition is 
not met (evaluates to false} . The activity set 
will be repeated one or more times. 
</xsd: documentation 
</xsd: annotation> 
<xsd : complexContent> 

<xsd: extension base="wsci :activity"> 
<xsd: sequence> 

: - e = " " 

type="wsci : condition" /> 
<xsd : group ref ="wsci : activitySet" /> 
</xsd : sequence> 
</xsd : extension> 
</xsd : complexContent> 
</xsd : complexType> 

<xsd: complexType name="while"> 
<xsd: annotation> 

<xsd:documentation> 

Repeats the activity set while the condition is 
met (evaluates to true) . The activity set will be 
repeated zero or more times. 
</xsd: documentation> 
</xsd: annotation> 

<xsd : extension base="wsci : activity"> 
<xsd: sequence> 

<xsd: element name="condition" 

type="wsci : condition" /> 
<xsd: group ref ="wsci : activitySet" / > 
</xsd: sequence> 
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</xsd:extension> 
</xsd : complexContent> 
</xsd: complexType> 



<!-- Type definitions for activity context — > 
<xsd: complex-Type name="context"> 

<xsd : documentation> 

Defines the context for an activity set. 

All activities within the set perform in this context. 
</xsd: documentation> 
</xsd : annotation> 
<xsd: sequence> 

<xsd: choice minOccurs="0" maxOccurs="Unbounded"> 

<xsd: element name="process" type="wsci :process"/> 

<xsd:element name="property" type="wsci :property"/> 
</xsd:choice> 

<xsd : element name="exception" 

minOccurs="0" maxOccurs=" 1 "> 
<xsd : annotation> 

<xsd: documentation^ 

Defines exception handling. 
</xsd:documentation> 
</xsd:annotation> 
< x s d : c o rnp 1 e x T yp e > 

<xsd : group ref ="wsci : anyEvent" 

minOccurs="l " maxC-ccu rs=" unbounded" /> 
</xsd:complexType> 

<xsd: unique name="exceptionFaultConstraint"> 

<xsd: selector xpath=" . /wsci :onFault"/> 

<xsd: field xpath="@code"/> 
</xsd:unique> 

<xsd : key name="exceptionTimeoutConstraint "> 
<xsd: selector xpath=" . /wsci : onTimeout" /> 
<xsd: field xpath="@property"/> 

</xsd: key> 

<xsd : element name=" transaction" 

minOccurs="0" maxOccurs="l"> 
<xsd:annotation> 

<xsd : documentation 

Defines the name of a transaction and the transaction 
type. Optionally defines compensating activity. 
</xsd: documentation> 
</xsd : annotations 
<xsd : complexType> 

<xsd: element name="compensation" 

minOccurs="0" maxOccurs=" 1 "> 
<xsd : complexType> 

<xsd : complexContent> 

<xsd : extension base="wsci : documented"> 

<xsd: group ref -"wsci : activitySet" /> 
</xsd: extension> 
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</xsd: complexContent> 
</xsd: complexType> 
</xsd:element> 
</xsd: sequence> 

< x s a : at t r i bu t e name= " name " t ype= "xsd: NCName " 

use=" required" /> 
<xsd: attribute name="type" type="wsci : transactionType" 

use=" optional" def ault=" atomic "/> 
<xsd: attribute name="retries" type="xsd:QName" 
use="optional"/> 
</xsd:complexType> 
</xsd : element> 
</xsd: sequence> 
</xsd : complexType> 

<xsd: complexType name="property"> 
<xsd: annotation> 

<xsd: documentations 

Defines a property within a context. 
</xsd:documentation> 
</xsd:annotation> 
<xsd: complexContent> 

<xsd : extension base="wsci : document ed"> 
<xsd: sequence> 

<xsd: element name="value" 

minOccurs="0" maxOccurs="l"> 
<xsd: complexType mixed="true"> 
<xsd: sequence> 

<xsd:any namespace="##other" processContents="skip" 
minOccurs="0" maxOccurs=" unbounded" /> 
</xsd: sequence> 
</xsd: complexType> 
</ xsd : element> 
</xsd: sequence> 

<xsd : attribute name="name" type="xsd:QName" 

use="required"/> 
<xsd: attribute name="select" type="wsci : expression" 

use="optional"/> 

</xsd : extension> 
</xsd: complexContent> 
</xsd: complexType> 

<!-- Element definitions --> 

<xsd:comp] exType name="process"> 
<xsd : annotation> 

<xsd:documentation> 

Defines a process. A process is an activity set that 
is not contained within any other activity. 
</xsd: documentation 
</xsd : annotations 
<xsd: complexContent> 

<xsd: extension base="wsci : nameRequired"> 
<xsd: group ref="wsci : activitySet"/> 

<xsd: attribute name="instantiation" type="wsci : instantiationType" 
use=" optional" def ault= "message" /> 
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</xsd:extension> 
</xsd: complexContent> 
</xsd: complexType> 

<xsd : complexType name="nameRequired"> 
<xsd : complexContent> 

<xsd: restriction base="wsci : activity" > 
<xsd : sequence> 

<xsd:element ref="wsci : documentation" minOccurs="0" maxOccurs=" 1 
</xsd: sequence> 

<xsd: attribute name="name" type="xsd:NCName" 
use =" required" /> 
</xsd: restriction> 
</xsd : complexContent> 
</xsd: complexType> 

<xsd: element name="interface"> 
<xsd: annotation> 

<xsd : documentation> 
TBD . 

</xsd: documentation> 

<xsd : complexType> 

<xsd : complexContent> 

<xsd: extension base="wsci : documented" > 
<xsd: sequence> 

<xsd:element name="process" type="wsci : process" 

minOccurs="l" maxOccurs= "unbounded" > 
<xsd: unique name="processContextNameConstraint"> 
<xsd:selector xpath="../*| . /wsci : context/*"/> 
<xsd : field xpath="@name"/> 
</xsd: unique> 
</xsd:element> 
</xsd:sequence> 

<xsd : attribute narae="name" type="xsd:NCName" 
use=" required" /> 

</xsd:extension> 
</xsd: complexContent> 
</xsd : complexType> 

<xsd: key name="processNameConstraint "> 

<xsd: selector xpath=" . /wsci :process"/> 

<xsd: field xpath="@name"/> 
</xsd:key> 
</xsd:element> 

<xsd : element name="model"> 
<xsd : annotation> 

<xsd: documentation> 
TBD. 

</xsd: document at ion> 
</xsd: annotation> 
<xsd : complexType> 

<xsd : complexContent> 

<xsd: extension base="wsci : documented"> 

<xsd: sequence minOccurs="l" maxOccurs=" unbounded" > 
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<xsd : element name=" interf ace"> 
<xsd : complexType> 

<xsd: attribute name="ref" type="xsd : QName" 
use="required"/> 
</xsd : complexType> 
</' xsd: element> 

<xsd: element name="connect" type="wsci : connect"/> 

<xsd: attribute name="name" type="xsd:l 
use="required"/> 

</xsd: complexContent> 
</xsd : complexType> 

<xsd: key name="interf aceNameConstraint"> 

<xsd: selector xpath=" . /wsci : interf ace"/> 

<xsd : field xpath="@name"/> 
</ xsd : key> 
</xsd:element> 

<xsd: compiexType name="connect"> 
<xsd:annotation> 

<xsd:docuraentation> 

Connects two operations in opposing port types. 
</xsd: documentation> 
</xsd : annotation> 
<xsd : complexContent > 

<xsd: extension base="wsci : documented" > 
<xsd: sequence> 

<xsd : any namespace="##other " processContents="strict" 
minOccurs="0" maxOccurs="l"/> 

<xsd: attribute name="operation" type="wsci : twoOpNames" 

use="optional"/> 
<xsd:anyAttribute namespace="##other " 

processContents=" strict "/> 

</xsd: complexContent> 
</xsd : complexType> 

</xsd: schema> 

8.4.2 Extended: Locate 

<xsd: schema, targe tNamespace="http : //www . w3 . org/2 002/ 07 /wscilO/locate" 
xmlns : xsd="http: //www . w3 . org/ 2 0 01 /XMLS chema" 
xmlns : wsci-core="http : //www . w3 . org/ 2002/07/ wscilO" 
xmlns :wsci-locate="http: //www. w3 .org/2 0 02/ 07 /wscilO /locate" 
element FormDef ault=" qualified" 
blockDefault="#all"> ' 

<xsd: import namespace-"http://www. w3.org/2002/07/wscil0" / > 

<xsd: element name-" locator" type- "wsci -locate : locator "/> 
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<xsd: complexType name=" locator"> 

Defines a locator. An extension element and optional 
extension attributes are used to define the mechanism 
by which the service instance is identified. 
</xsd: documentation 
</xsd : annotation> 
<xsd: complexContent> 

<xsd: extension base="wsci-core : documented" > 
<xsd: sequence> 

<xsd:any namespace="##other" processContents="strict" 
minOccurs="l" maxOccurs="l"/> 

<xsd: attribute name- "name" type="xsd : NCName" 

use=" required "/> 
<xsd: anyAttribute namespace="##other" 

processContents=" strict" /> 

</xsd:extension> 
</xsd:complexContent> 
</xsd : complexType> 

<xsd: element name=" locate" type="wsci -locate : locate "/> 

<xsd : complexType name=" locate"> 
<xsd:annotation> 

<xsd: documentation^ 

Locates a service instance. The property attribute 
names the properties that are used to locate the 
service instance. The locator attribute references 
a locator definition. If absent, the service is located 
by its end-point URI given by a single property. 
</xsd:documentation> 
</xsd:annotation> 

<xsd: attribute name="property" type="wsci-core : listOfQName" 

use="optional"/> 
< x s d : attribute name=" locator" type="xsd : QName " 

use="optional"/> 
</xsd:complexType> 

</x : ii . 
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